3.4.3. Design and Configuration Vulnerabilities
💡 First Principle: Configuration and design vulnerabilities are often more dangerous than code vulnerabilities because they reflect systemic failures — insecure defaults affect every installation, and insecure designs affect the entire application, not just one function.
Broken Access Control — The application fails to enforce what authenticated users are allowed to do. Users can access other users' data, perform admin functions, or access resources they shouldn't. Examples: directly browsing to /admin without being an admin, accessing another user's profile by changing an ID in the URL (IDOR — Insecure Direct Object Reference).
Cryptographic Failures — Using weak or outdated cryptographic algorithms, storing passwords in plaintext or with weak hashing (MD5, SHA-1 without salt), transmitting sensitive data over HTTP, using hard-coded encryption keys.
Insecure Design — Fundamental architectural flaws that cannot be patched away — they require redesign. Example: a password reset flow that allows brute-forcing the reset code because there's no rate limiting. Secure design requires threat modeling during development.
Security Misconfiguration — Default credentials not changed, unnecessary features enabled, verbose error messages exposing stack traces and internal paths, unnecessary services running, missing security headers (CSP, HSTS, X-Frame-Options).
End-of-Life / Outdated Components — Running software versions that no longer receive security patches. EOL components represent permanent, unremediable vulnerability exposure until replaced.
Identification and Authentication Failures — Weak passwords allowed, credentials transmitted in plaintext, missing MFA, broken session management (session IDs predictable, not invalidated on logout, exposed in URLs).
Data Poisoning — Attacker corrupts training data (ML models), cached content, or DNS records to manipulate application behavior or mislead detection systems.
| Vulnerability Class | OWASP 2021 Rank | Primary Prevention |
|---|---|---|
| Broken Access Control | #1 | Server-side authorization checks; deny by default |
| Cryptographic Failures | #2 | Modern algorithms; never roll your own crypto |
| Injection | #3 | Parameterized queries; output encoding |
| Insecure Design | #4 | Threat modeling; security requirements |
| Security Misconfiguration | #5 | Hardening baselines; automated config scanning |
| EOL/Outdated Components | #6 | SCA tools; patch management; EOL tracking |
| Auth Failures | #7 | MFA; strong session management |
⚠️ Exam Trap: "Security misconfiguration" is the broadest OWASP category — it includes default credentials, open cloud storage buckets, unnecessary admin interfaces exposed to the internet, and missing security headers. When an exam scenario describes an exposed service with default settings that was never intentionally configured for security, that's security misconfiguration.
Reflection Question: A web application stores user passwords by hashing them with MD5 without a salt. A breach exposes the database. An attacker with rainbow tables can crack 80% of passwords in minutes. Which OWASP category does this fall under, and what two specific technical controls would have prevented this outcome?
