This chapter argues that many software teams inadvertently sideline security by treating it as a collection of features to add later, rather than as a cross-cutting concern to be met by the system’s overall shape. It proposes a mindset shift: emphasize design—the continuous, all-levels decision-making that shapes code, models, APIs, and architecture—so that security emerges naturally. Framing security in terms of concerns like confidentiality, integrity, availability, and traceability, the authors show that strong design choices often satisfy these needs more reliably than checklists of security add-ons.
The traditional approach—asking every developer to constantly “think security,” be a security expert, and anticipate every attack—doesn’t scale and routinely fails in practice. Instead, the chapter demonstrates how precise domain modeling and explicit constraints make systems secure by construction. Turning a free-form username String into a dedicated value object with strict invariants prevents whole classes of issues (such as XSS) without developers explicitly chasing vulnerabilities. This design-first approach aligns with developers’ core interests, removes false trade-offs between business features and security, enables non-experts to write safer code, and often neutralizes bugs implicitly—while still benefiting from complementary practices like reviews and testing.
To illustrate security-through-design at a larger scale, the chapter tackles the Billion Laughs XML entity expansion attack. It cautions against overly generic data types and prescribes a validation order (length, lexical content, then syntax). Secure XML handling blends multiple design layers: hardening parser settings, performing a lightweight lexical scan to reject entities and ensure required elements exist before parsing, and applying operational constraints (such as resource limits) to contain worst cases. The result is defense in depth: even if one layer is bypassed, others hold. Across these examples, the chapter’s core message is that embedding careful, domain-driven design into everyday development yields stronger, more maintainable security than bolt-on features or after-the-fact fixes.
Having only a login page doesn’t help much.
Traditionally, software security is viewed as explicit activities and concepts.
A focus on design rather than on security avoids issues with the traditional approach to security.
Exploring concepts with domain experts to gain deeper insight into the domain
Summary
It’s better to view security as a concern to be met than to view it as a set of features to implement.
It’s impractical to achieve security by keeping it at the top of your mind all the time while developing. A better way is to find design practices that guide you to more secure solutions.
Any activity involving active decision-making should be considered part of the software design process and can thus be referred to as design.
Design is the guiding principle for how a system is built and is applicable on all levels, from code to architecture.
The traditional approach to software security struggles because it relies on the developer to explicitly think about security vulnerabilities while at the same time trying to focus on implementing business functionality. It requires every developer to be a security expert and assumes that the person writing the code can think of every potential vulnerability that can occur now or in the future.
By shifting the focus to design, you’re able to achieve a high degree of software security without the need to constantly and explicitly think about security.
A strong design focus lets you create code that’s more secure compared to the traditional approach to software security.
Every XML parser is implicitly vulnerable to entity attacks because entities are part of the XML language.
Using generic types to represent specific data is a potential door opener for security weaknesses.
Choosing the XML parser configuration is difficult without understanding the underlying parser implementation.
Secure by design promotes security in-depth by adding several layers of security.
FAQ
What does “security is a concern, not a feature” actually mean?It means you shouldn’t treat security as a checklist of add-ons (like “add login” or “enable logging”). Instead, frame security as outcomes to preserve across the whole system, such as “only owners can see their photos” or “all changes are attributable.” This shifts focus from isolated features to meeting cross‑cutting concerns everywhere they apply.How does focusing on design improve security without “thinking security” all the time?Good design choices (precise domain types, clear invariants, high cohesion, low coupling) naturally constrain what the system allows. By making illegal states unrepresentable and enforcing rules at boundaries, many security issues disappear as a byproduct of better models and APIs, reducing the need for constant vulnerability-by-vulnerability defenses.What are the main security concerns captured by CIA‑T?CIA‑T stands for Confidentiality (keep data secret), Integrity (prevent unauthorized changes), Availability (ensure timely access), and Traceability (know who accessed or changed what, and when). These concerns guide what must be protected and how to prove it.Why does the traditional “train everyone, add security tasks” approach fall short?It often relies on developers continually prioritizing security alongside features, assumes broad security expertise, and expects teams to anticipate known and unknown attack vectors. In practice, feature delivery wins, expertise varies, and gaps remain—leading to recurring vulnerabilities.How can domain modeling and precise types prevent bugs like XSS?Represent domain concepts with explicit types and invariants (for example, a Username that only allows [A–Z, a–z, 0–9, _ , -] and a bounded length). By validating once at creation and passing validated objects around, you eliminate dangerous inputs at the source and reduce attack surface across the app.Why do security tasks get deprioritized, and how does a design mindset help?Security often competes with visible features, is hard to value, and can feel abstract. A design-led approach folds security into the domain model and API design, so you’re not trading “security work” against “feature work”—you’re building features with security baked in.What is the Billion Laughs attack?It’s an XML entity expansion attack where small, nested entity definitions explode into huge payloads during parsing, consuming massive memory and potentially crashing services. The trick is exponential growth via recursive entity references.How do I process XML securely without breaking legitimate use cases?Apply defense in depth: (1) configure the XML parser to restrict or disable dangerous entity behaviors; (2) perform a lexical content scan to reject inputs with disallowed constructs and ensure required elements exist before parsing; and (3) add operational constraints (quotas, sandboxing, process isolation) so even if expansion happens, it can’t exhaust shared resources.In what order should input validation be done, and why?Use this sequence: (1) length checks (cheap, fail fast), (2) lexical content checks (characters and encoding), (3) syntax checks (format/structure). This order prevents expensive parsing of obviously bad inputs and reduces risk from crafted payloads.Does “secure by design” replace penetration testing and other security work?No. Secure by design reduces classes of bugs and makes systems sturdier, but you still need explicit security practices: penetration testing, threat modeling, secure output encoding, and ongoing reviews. Stay eclectic: combine strong design with targeted security activities and layered defenses.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
Secure by Design ebook for free
