Secure by Design, Revisited - Insights & Pitfalls
summary
Argues that validated domain primitives (example: Swedish tax id class that encapsulates format, checksum and birthdate logic) stop injection by making invalid values unrepresentable and expose a bug fix (handling people turning 18 on election day) when interpretation moves inside the object. Reframes validation as five steps — origin, size, lexicon, syntax, semantic/state — and recommends APIs enforce state checks with 422/405 rather than blind 200s. Advises to fetch secrets on demand (use a vault) to enable live DB password rotation instead of startup-only injection.
AI-written summary · about
chapters (10)
- 0:00Start
- 4:44Software bugs
- 10:34Secure by Design - Overview
- 13:50Let's consider a Swedish Tax ID Structure of an ID How does this get represented in code? Which data type is used? 1 control digt
- 15:36Common Representation in Code
- 18:32The misconception Explicit and validated types with domain logic outside of the object
- 29:50The misconception: "validation" = "input argument validation"
- 31:15Book Order object example
- 38:23Externalized Secrets
- 39:43Misconception: config injection at startup
related talks
59mSecure Coding Back to Basics
46mSecure Coding Patterns
40mSecure Software & Domain Driven Design
38mSecure Coding: Back to basics
01h 17mSecure by Design - Security Principles for the Working Architect
29mSecurity by(e) Design?
58mBuilding antifragile systems using Secure by Design
37mSecurity Doesn’t Have To Be a Nightmare