Secure Coding: Back to basics
summary
Claims that making domain concepts explicit stops many bugs: use domain primitives (email/password/phone types) so wrong strings become compile errors, validate via Kotlin/Either instead of exceptions, and push semantics into entities. Quantifies risk: about 50% business logic bugs evade scanners. Practical fixes: use DTO/contract layer to prevent mass assignment, always use parameterized queries or browser trusted types plus DOMPurify for XSS. Examples and a password-validator service are implemented and reported to reduce runtime vulnerabilities.
AI-written summary · about
chapters (16)
- 0:00Intro
- 2:40Bug types in order of personal preference
- 6:16The multifaceted entity
- 8:34Syntax versus semantics
- 9:07Validating a birth date
- 10:18Principle: Normalize input
- 11:12Principle: Reject invalid input
- 14:20Domain Driven Security by example
- 15:22The Domain Primitive
- 19:40Some validation needs to be enforced outside the primitives
- 20:44The UserRegistration Entity
- 21:40Domain validation of password
- 27:53API Controller responsibilities
- 31:16Encoding and language constructs to the rescue
- 31:47Confession - I failed to communicate
- 36:11Trusted Types - the default policy
related talks
59mSecure Coding Back to Basics
52mSecure by Design, Revisited - Insights & Pitfalls
50mCracking the Code to Secure Software
46mSecure Coding Patterns
40mSecure Software & Domain Driven Design
51mPreventing Security Bugs through Software Design
52mArm yourself with Domain Driven Security. It's time to slay some security trolls?
46mStrengthening Java Apps: Best Practices in Secure Coding for Java Developers