Insecure Design
Architectural decisions that create vulnerabilities no amount of clean implementation can fix.
What it is
Insecure Design moves from A04:2021 to A06:2025. It covers vulnerabilities that are baked into the system before any line of code is written: business logic flaws (rate limits that are not enforced, password reset flows that allow account takeover by design, file upload features that cannot be safely implemented), missing threat modeling, and reliance on user-supplied trust labels. Unlike injection or auth bugs, insecure design issues persist through code-level fixes because the design itself is the vulnerability.
Common patterns
- •File upload features without a viable threat model (allowed types, storage location, serving behavior).
- •Password reset flows that confirm reset based on knowledge of public information.
- •Rate limits enforced client-side, or applied per IP rather than per identity, or absent entirely.
- •Multi-tenant architectures that scope by request parameter rather than by the authenticated identity.
- •Privileged operations that rely on the absence of a UI link to remain undiscovered ('security by obscurity').
- •Workflows that assume an out-of-band step has occurred when it has not been verified.
What Deva detects
Insecure design is partly architectural and not fully detectable by code-level static analysis. Deva surfaces structural smells (file uploads without extension allowlists, missing rate limits on auth endpoints, absent CSRF tokens on state-changing routes) but cannot replace threat modeling. The Custom Compliance Framework Builder lets teams encode their own design rules (for example: every payment route must touch the audit log) so design intent is enforced at scan time.
CWE detection guides
Real-world examples
| Year | Incident | What happened |
|---|---|---|
| 2019 | Twitter SMS-based 2FA design | Twitter's design tied 2FA to phone numbers in a way that could be hijacked via SIM-swap attacks. The flaw was structural: any system that uses SMS as a second factor inherits SIM-swap risk. The design has since been deprecated industry-wide for high-value accounts. |
| 2017 | Equifax web portal credentials | An internal portal used 'admin' as both the username and password, an insecure-design pattern that bypassed any code-level authentication strength. Code review did not catch this because the choice was a configuration decision. |
Compliance framework impact
- •NIST 800-53 SA-8 Security Engineering Principles, SA-11 Developer Security Testing
- •PCI-DSS v4.0 Req 6.2 Secure software development
- •CMMC 2.0 SA.L2-3.1.20 External system protections
Deva detects the insecure design patterns above at write time, alongside 970+ other CWE rules, with fixes mapped to the compliance controls each finding touches.