Secure Coding Patterns
summary
Argues that validation must make domain-driven security concrete by treating primitive inputs as untrusted and only passing validated domain objects (constructed-validated and preferably immutable); shows path normalization before validation, log-injection and path-traversal examples, and a shopping-wizard race fixed by clone-with-new-object immutability. Proposes an Untrusted<T> wrapper implemented via C# internalsVisibleTo or C++ friend/implicit constructors to force validation, advocates immutability to avoid TOCTOU, and recommends Optional<T> instead of null.
AI-written summary · about
chapters (12)
- 0:00Start
- 1:26Domain Driven Security
- 2:34Authentication
- 8:32Domain-Driven Security
- 11:46Domain Objects
- 15:47Domain-Driven Security Essentials
- 19:44The Untrusted Pattern
- 23:07Assembly Directives
- 31:36Make Data Immutable
- 33:33Inverse Life-Coach Pattern
- 36:29Consider Your Trust Boundaries
- 43:42Builder Pattern
related talks
59mSecure Coding Back to Basics
52mSecure by Design, Revisited - Insights & Pitfalls
40mSecure Software & Domain Driven Design
38mSecure Coding: Back to basics
52mArm yourself with Domain Driven Security. It's time to slay some security trolls?
50mCracking the Code to Secure Software
25mLittle Bobby Tables: Understanding Data Validation and Sanitization
31mAchieving Secure Software through Redesign