Paved roads: making the secure choice the easy choice, by default
Every lesson in this domain, and most of Web Security's, has ultimately come down to a developer remembering to do the right thing, every single time, across every single code path — parameterize the query, check ownership, escape the output. That's a genuinely fragile strategy at the scale of a real engineering org, and it has a real, different fix.
Advanced
3 min read
Why "just remember to do it right" doesn't scale
Every specific mechanical fix this curriculum has covered — parameterized queries, explicit ownership checks, allowlist validation — is simple to apply in the one file a developer is looking at right now. The actual failure mode at scale isn't that any individual developer doesn't understand these fixes; it's that a codebase with hundreds of call sites, touched by dozens of engineers over years, only needs one of those call sites to skip the fix for a real vulnerability to exist — and relying purely on every single developer remembering every single rule, every single time, is a strategy that degrades predictably as a codebase and team grow.
The paved-road idea: make the safe default the path of least resistance
A paved road is shared tooling — a library, a framework default, a code-generation template — that makes the secure behavior the easiest thing to do, rather than an extra step a developer has to remember and deliberately choose. A shared internal HTTP client that automatically blocks requests to private IP ranges closes the SSRF class of vulnerability for every single call site that uses it, permanently, without depending on each individual developer separately recalling Web Security's SSRF lesson every time they write a new outbound request.
Concrete examples of paved roads for vulnerability classes this curriculum already covered
SQL injection (Web Security): an ORM, or a query builder that structurally can't accept a raw concatenated string, makes parameterization the only option, not a rule to remember.
XSS (Web Security): a frontend framework that escapes all rendered content by default (the way React does) makes the unsafe path — dangerouslySetInnerHTML, an explicit opt-out — visibly unusual and deliberate, rather than the default a developer reaches for without thinking.
OS command injection (lesson 1): a shared subprocess-wrapping utility that only accepts an argument list, never a raw shell string, removes the unsafe option from the API surface entirely rather than trusting every call site to remember shell=False.
Mass assignment (lesson 3): a shared serializer base class that requires an explicit allowlist of fields per endpoint, with no "just bind everything" shortcut available at all.
Why this is a genuinely different kind of fix than anything else in this domain
Every other lesson in this curriculum fixes one specific instance of a vulnerability, in one specific piece of code. A paved road fixes an entire class of future vulnerability, for every future piece of code that uses it, written by developers who may never have read this lesson or Web Security's at all — it moves the security property from "something every developer must independently know and apply correctly" to "something the tooling itself guarantees structurally," which is a categorically more reliable guarantee at any real scale.
The honest limitation: paved roads don't eliminate the need for everything else
A paved road only protects call sites that actually use it — code that bypasses the shared library (intentionally, or because it predates the library's existence) gets none of the benefit, and a sufficiently unusual, one-off requirement will sometimes genuinely need to step off the paved road deliberately. Building and maintaining these shared tools is a real, ongoing investment, not a one-time fix — and it complements secure code review and threat modeling (Web Security's own lesson on both) rather than replacing the need for either; a paved road handles the common case structurally, a human reviewer still needs to catch the deliberate exceptions.