OWASP Top 10: A Practitioner's Guide to Finding and Fixing Each Vulnerability

A01 — Broken Access Control is the most prevalent vulnerability in tested applications. It occurs when the application fails to enforce what authenticated users are allowed to do. The most common patterns: insecure direct object references (changing an ID in a URL to access another user's data — https://app.com/invoice/1234 to /invoice/1235), missing function-level access control (a non-admin user directly calling an admin API endpoint because the UI does not show the button but the API has no server-side check), and CORS misconfiguration allowing untrusted origins to make credentialed requests. Remediation requires server-side enforcement on every request — never trust the client to enforce access decisions — and a default-deny model where access is explicitly granted rather than explicitly denied.

A02 — Cryptographic Failures (formerly Sensitive Data Exposure) covers inadequate protection of sensitive data in transit and at rest. Common failures: transmitting sensitive data over HTTP rather than HTTPS, storing passwords with MD5 or SHA-1 rather than bcrypt/Argon2/scrypt, using ECB mode block ciphers that produce deterministic output, hardcoding encryption keys, and using weak random number generation for cryptographic purposes. The remediation principle: do not implement cryptography yourself. Use vetted libraries (libsodium, the language's standard crypto library) for the specific operation, and use bcrypt/Argon2 specifically for password hashing.

A03 — Injection covers SQL, LDAP, OS command, and NoSQL injection. SQL injection remains prevalent despite being a solved problem: parameterized queries with prepared statements prevent SQL injection entirely regardless of input content. The failure mode is almost always string concatenation to build queries rather than parameterized execution. For OS command injection, the fix is to avoid shell execution with user-controlled input entirely — use language-native library calls rather than exec() or system() calls that pass user input to the shell.

A04 — Insecure Design is the only OWASP category that cannot be fixed by patching code — it requires redesigning the system. It covers threat modeling failures, missing rate limiting on sensitive operations (allowing brute force attacks against authentication or enumeration of user data), missing business logic controls (allowing negative quantities in shopping carts, allowing unlimited promotional code use), and APIs that expose more data than required.

A05 — Security Misconfiguration is the second-most prevalent category. It includes: default credentials left in production (admin/admin, database password of 'password'), unnecessary features enabled (development endpoints, debug modes, verbose error messages that expose stack traces), overly permissive cloud IAM policies (S3 buckets public by default, IAM roles with wildcard resource permissions), and missing security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security). Automated configuration scanning (AWS Config, cloud security posture management tools, Trivy for container images) catches the majority of misconfiguration issues at deploy time rather than after breach.

A06 — Vulnerable and Outdated Components remains in every OWASP Top 10 edition because the operational hygiene required to fix it is genuinely difficult at scale. Every dependency in your application (npm packages, Python packages, Maven dependencies, Docker base images) potentially carries known CVEs. Software Composition Analysis (SCA) tools — Snyk, OWASP Dependency-Check, GitHub Dependabot, Mend — scan your dependency tree against CVE databases and alert when vulnerable versions are detected. The remediation is straightforward: keep dependencies current, remove unused dependencies, and enforce SCA scanning in your CI/CD pipeline as a blocking gate for high-severity CVEs.

A07 — Identification and Authentication Failures covers credential stuffing exposure (no account lockout or rate limiting on login endpoints), weak password policies, missing MFA, session tokens that do not expire on logout, session IDs passed in URLs (exposing them in referrer headers and server logs), and predictable session token generation. The minimum viable authentication security baseline: rate-limit login attempts per IP and per account, invalidate session tokens server-side on logout, use a cryptographically secure random token generator for sessions, enforce MFA for privileged accounts and any function involving financial transactions or sensitive data access.

A08 — Software and Data Integrity Failures covers deserialization of untrusted data, missing subresource integrity checks for third-party scripts loaded from CDNs, and CI/CD pipelines that automatically deploy unsigned or unvalidated artifacts. The web skimming attacks that PCI DSS v4.0 Requirement 6.4.3 now specifically addresses fall under this category — third-party scripts loaded without integrity verification can be modified at the source to exfiltrate payment data.

A09 — Security Logging and Monitoring Failures is the application-layer equivalent of the SIEM coverage problem. Applications that do not log authentication events, access control failures, and input validation failures leave incident responders without the forensic data needed to determine what happened and what data was accessed during a breach. Log the events that matter: successful and failed logins with source IP, access control failures (including the resource and the user), input validation failures for security-relevant fields, and all actions taken by privileged users. Store logs externally to the application server — logs on a compromised server can be deleted.

A10 — Server-Side Request Forgery (SSRF) has risen sharply in cloud environments. SSRF occurs when an attacker can cause the server to make HTTP requests to attacker-specified URLs. In cloud environments, this commonly enables access to the instance metadata service (169.254.169.254 in AWS) to retrieve IAM credentials. Remediation: validate and allowlist URLs the server is permitted to request, block access to RFC-1918 addresses and the cloud metadata endpoint from application network policy, and use IMDSv2 (token-based metadata service) in AWS to require a PUT pre-flight request that browser-based SSRF cannot satisfy.

Treating the OWASP Top 10 as an AppSec program requires mapping each category to detection and prevention controls across the development lifecycle.

For developer training: use the OWASP Top 10 as the curriculum backbone for secure coding training. Each category maps to specific code patterns developers should recognize and avoid. The most effective training format is code review exercises — showing developers actual vulnerable code and asking them to identify the vulnerability — rather than lecture-based training.

For SAST tooling: configure your static analysis tool (Semgrep, CodeQL, Checkmarx, Veracode) with rule sets that cover each OWASP category. Not all SAST tools cover all categories equally — A01 (Broken Access Control) is notoriously difficult to detect statically because access control logic is application-specific. Supplement SAST with manual code review for access control logic.

For DAST tooling: run DAST scanners (OWASP ZAP, Burp Suite, Invicti) against your applications in staging environments. DAST is more effective than SAST for A05 (misconfiguration), A07 (auth failures), and A10 (SSRF) because these require dynamic interaction with the running application rather than source code analysis.

For penetration testing: map your pentest scope to OWASP Top 10 categories and require your pentest provider to test each category explicitly. A pentest report that does not address every OWASP category has coverage gaps.

The OWASP Top 10 represents the vulnerability classes that appear most consistently across web application security assessments. None of the ten categories is technically exotic — they all have well-understood root causes and well-documented remediation. The gap between organizations that repeatedly find OWASP Top 10 issues in their applications and organizations that have systematically eliminated them is almost entirely a function of developer training, SAST/SCA integration in CI/CD, and code review standards — not tooling sophistication.