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. The fix for stored passwords is not a different fast hash or one shared salt: re-hash with a deliberately slow, adaptive password-hashing algorithm (bcrypt, scrypt, Argon2 or PBKDF2) using a unique random salt per user and a tuned work factor, so rainbow tables are useless and GPU cracking is expensive (OWASP Password Storage Cheat Sheet).

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).

Security headers and cookie flags — Each missing header maps to an attack class. X-Frame-Options (or CSP frame-ancestors) stops the page being embedded in another site's iframe, which prevents clickjacking. X-Content-Type-Options: nosniff stops the browser guessing a different MIME type for a response, which prevents MIME-sniffing attacks. Content-Security-Policy restricts where scripts may load from, limiting XSS and injected external scripts. HSTS forces HTTPS. These are browser-side controls; they do nothing against SQL or command injection. Session cookies are hardened with three attributes: HttpOnly (JavaScript cannot read the cookie, limiting theft through XSS), Secure (sent only over HTTPS) and SameSite (not attached to most cross-site requests, limiting CSRF).

Legacy protocols — Disable protocols that are insecure by design when nothing needs them: SMBv1 (the protocol exploited by EternalBlue, and so by the WannaCry and NotPetya worms), Telnet (credentials and commands in cleartext; replace it with SSH and update the scripts that depend on it) and SSL/TLS 1.0/1.1. Disabling an unused protocol is a configuration remediation and needs no patch.

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). Session tokens placed in URLs leak through server and proxy logs, browser history and the HTTP Referer header sent to other sites, so tokens belong in cookies. Token formats have their own failures: an API that honors a JSON Web Token (JWT) header of alg: none, or does not verify the signature, accepts forged unsigned tokens and bypasses authentication entirely. Servers must pin the expected algorithm and always verify the signature.

Data Poisoning — Attacker corrupts training data (ML models), cached content, or DNS records to manipulate application behavior or mislead detection systems.

⚠️ 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?