Module 10 · The Framework-Assumption Gap 🔒

The most dangerous phrase in modern web security is “the framework handles that.” Rails handles CSRF tokens. Django handles SQL injection. React handles XSS. Spring handles authorization. Each of these statements is partially true and completely dangerous. This module is about where framework defenses end and developer responsibility begins — the gap where modern vulnerabilities live.

Why this happens

Modern frameworks absorb the responsibility for the most common security patterns. This was a net win for web security: CSRF tokens everywhere, SQL injection largely dead in ORM-using apps, XSS mostly blocked in modern SPA defaults. The cost: developers stopped thinking about security because the framework “handles it.”

But frameworks handle the default case. The non-default case — anywhere you opt out, use escape hatches, integrate with a third party, or step outside the framework’s paved path — is your responsibility again, without the habitual attention that produces good decisions. Vulnerabilities concentrate at these junctions.

The escape-hatch failure pattern

Every framework has one. Django: raw SQL via .raw(). React: dangerouslySetInnerHTML. Rails: raw() and html_safe. Angular: bypassSecurityTrust* family. Spring: raw HTML generation. Every escape hatch exists because sometimes the default isn’t what you need.

The developer uses the escape hatch in the one legitimate case. Then copies that code for a slightly different case. Then uses the same pattern in a third place where it’s no longer safe. The escape hatch spreads, and each use is a potential vuln.