OWASP Top 10 in Plain English: What Each Vulnerability Looks Like in a Real Code Review

The OWASP Top 10 has been updated several times since its first publication in 2003, but its core insight hasn't changed: most successful web application attacks exploit a small set of well-understood vulnerability classes that appear repeatedly across different codebases, languages, and architectures. These aren't exotic zero-days — they're the same categories of mistakes, made over and over again, by engineers who knew about the risks but didn't recognize them in the specific code in front of them.

Recognition is the skill that separates a useful code review from a cursory one. Here's what each major vulnerability class looks like in real code.

A01: Broken Access Control

This is the most prevalent vulnerability category and it shows up in code reviews as missing authorization checks. Look for API endpoints that accept a resource identifier (user ID, document ID, order number) as a parameter and query the database directly without verifying that the authenticated user has permission to access that specific resource. The query might return data correctly — the bug is that it returns it for any user who provides the right ID, not just the owner.

A02: Cryptographic Failures

In code reviews, this appears as: passwords stored as MD5 or SHA-1 hashes (use bcrypt or Argon2), sensitive data transmitted over HTTP rather than HTTPS, encryption keys hardcoded in source code, use of custom cryptographic implementations rather than well-reviewed libraries, and weak random number generators used for security tokens. The red flag pattern: any code that directly touches user passwords, API keys, or session tokens deserves extra scrutiny of the cryptographic choices made.

A03: Injection

SQL injection is the classic example, but injection vulnerabilities appear in any context where user input is incorporated into a command or query interpreted by an interpreter. In code reviews: look for string concatenation where parameterized queries should be used, template literal construction of shell commands, LDAP queries built from user input, and XML/HTML generation that incorporates unsanitized user data. The safe pattern is always: parameterize or escape inputs at the interpreter boundary, not at the point where the input enters the system.

A04: Insecure Design

This category is the hardest to spot in a code review because it often manifests as the absence of something rather than the presence of something wrong. Missing rate limiting on authentication endpoints. No account lockout after failed password attempts. Password reset flows that don't expire tokens or verify ownership. Workflows that skip confirmation steps for irreversible actions. These require the reviewer to mentally model the abuse cases rather than just read the code path.

A05: Security Misconfiguration

In code reviews, this appears as: verbose error messages that expose stack traces or internal paths in production, debug endpoints left enabled, default credentials not changed, overly permissive CORS configurations, missing security headers (CSP, HSTS, X-Frame-Options), and unnecessary features or endpoints left enabled. A security misconfiguration checklist as part of your review process for infrastructure and configuration changes catches most of these.

A06: Vulnerable and Outdated Components

This isn't caught in traditional code review — it requires dependency scanning. Automated tools (GitHub Dependabot, Snyk, npm audit) do this better than human reviewers can. The important thing to catch in code review is the addition of new dependencies: any PR that adds a new package dependency should include a brief justification of the package's provenance, maintenance status, and necessity.

A07: Identification and Authentication Failures

Review for: session tokens that don't expire, logout that doesn't invalidate the server-side session, session fixation vulnerabilities (where the session ID doesn't change after authentication), weak password requirements, credential exposure in URLs or logs, and remember-me implementations that use predictable or persistent tokens.

A08: Software and Data Integrity Failures

This category covers deserialization of untrusted data, auto-update mechanisms that don't verify signatures, and CI/CD pipelines that pull from untrusted sources. In code reviews: any deserialization of user-supplied data (JSON.parse, pickle.loads, PHP unserialize) deserves careful scrutiny of what the deserialized object is allowed to do.

A09: Security Logging and Monitoring Failures

A useful code review question for any authentication, authorization, or sensitive data access code: is this event being logged in a way that would make an incident detectable and analyzable? Missing logs for failed authentication attempts, missing logs for authorization failures, and logs that include sensitive data rather than just identifiers are all issues worth flagging.

A10: Server-Side Request Forgery (SSRF)

SSRF appears in any feature where user-supplied URLs are fetched by the server — URL preview features, webhook configurations, image upload by URL, API proxies. The vulnerability allows an attacker to make the server fetch internal resources on their behalf. In code reviews: any server-side HTTP request where the destination URL is influenced by user input should include validation that restricts the request to expected domains and blocks private IP ranges.

Security review isn't a separate step — it's a lens applied to every code review. These patterns are recognizable with practice. The engineers who catch them reliably aren't security experts with specialized training — they're engineers who've learned what each category looks like in real code and apply that knowledge consistently.