OWASP Top 10: What Every Development Team Needs to Know

The OWASP Top 10 is the closest thing the security industry has to a universally accepted minimum security baseline. First published in 2003 and updated in 2021, it lists the ten most critical security risks for web applications based on data from hundreds of organizations and thousands of real-world vulnerabilities. If your application has any of these problems, an attacker will find them before you do.

What most engineering teams miss is that the OWASP Top 10 is not a checklist to tick once at launch. Each category represents a class of vulnerabilities that can be introduced by any developer on any sprint. Understanding how they appear in real code is the difference between a team that uses OWASP as a document and a team that actually ships secure software.

A01: Broken Access Control

Access control failures moved to the top position in 2021, appearing in 94% of tested applications. The pattern is consistent: an endpoint checks authentication (is the user logged in?) but fails to check authorization (is this user allowed to do this specific thing?).

The most common manifestation is insecure direct object reference (IDOR): a user with ID 1234 requests /api/invoices/5678 and receives an invoice belonging to a different customer because the endpoint checks only that the user is authenticated, not that the invoice belongs to them. This vulnerability is invisible to automated scanners that do not understand your application's business logic.

Remediation requires enforcing authorization at every data access layer, not just at the route level. Every database query that returns user-owned data should filter by the authenticated user's ID, not accept an ID from the request.

A02: Cryptographic Failures

Previously named "Sensitive Data Exposure," this category was renamed to emphasize the root cause: applications fail to protect sensitive data because they fail to apply cryptography correctly. The failure modes include storing passwords with MD5 or SHA-1 instead of bcrypt, scrypt, or Argon2; transmitting sensitive data over unencrypted HTTP; and using symmetric encryption with hardcoded or predictable keys.

The most dangerous pattern is developers treating base64 encoding as encryption. Base64 is reversible with a one-line command and provides zero security. Any sensitive data — PHI, PII, credentials, session tokens — must be encrypted with a vetted algorithm, not encoded.

A03: Injection

SQL injection has been in the OWASP Top 10 since the first version. It remains widespread because developers continue to construct queries with string concatenation rather than parameterized queries or prepared statements. The same class of vulnerability applies to OS command injection, LDAP injection, and XML injection.

Modern ORMs reduce but do not eliminate injection risk. Raw query escape hatches in ORM-heavy codebases are a common injection surface, as are search features, report generation endpoints, and any functionality that passes user input to an external system. Code review that checks every data flow from user input to external interpreter is the only reliable defense.

A04: Insecure Design

A04 is distinct from implementation bugs: it covers vulnerabilities that result from architectural decisions rather than coding mistakes. A password reset flow that lets an attacker enumerate valid email addresses, or a rate limiting design that resets the counter on logout, are insecure designs that no amount of careful coding can fix after the fact.

Threat modeling during design — asking "how could an adversary abuse this feature?" before writing a line of code — is the remediation OWASP recommends. Security requirements belong in the design phase, not the QA phase.

A05: Security Misconfiguration

Security misconfiguration is the most commonly found issue in practice because it spans every layer of the stack: cloud infrastructure defaults, framework security settings, verbose error messages that expose stack traces, default credentials left unchanged, and unnecessary features or services left enabled.

Development configurations that leak into production are a frequent source of critical findings. Debug mode enabled in production, CORS configured to allow all origins, and directory listing enabled on web servers are all security misconfigurations that are trivial to identify and exploit but easy to miss in a fast-moving deployment pipeline.

A06: Vulnerable and Outdated Components

Dependencies with known vulnerabilities are responsible for some of the most damaging breaches in recent history. The 2017 Equifax breach exploited a known vulnerability in Apache Struts that had been publicly disclosed and patched two months earlier. The organization simply had not applied the patch.

Maintaining visibility into your dependency tree, monitoring for new disclosures, and applying patches quickly are operational requirements, not optional improvements. Automated dependency scanning on every pull request is the minimum viable program; it must be supplemented with scheduled scans that catch vulnerabilities disclosed after your last merge.

A07: Identification and Authentication Failures

Authentication vulnerabilities include weak password policies, missing account lockout after repeated failed attempts, insecure credential storage, and session management failures such as session tokens that do not expire or are transmitted in URLs rather than secure cookies.

Multi-factor authentication substantially reduces risk from credential-based attacks, but MFA implementations can themselves be vulnerable: SMS-based MFA is susceptible to SIM swapping, and poorly implemented TOTP can be bypassed if the server does not enforce one-time use of codes.

A08: Software and Data Integrity Failures

A08 covers scenarios where code or data is used without integrity verification: CI/CD pipelines that pull dependencies without verifying checksums, deserialization of untrusted data without validation, and auto-update mechanisms that do not verify signatures.

The SolarWinds attack is the canonical example of a software integrity failure: malicious code was inserted into a trusted software build process and distributed to thousands of customers as a signed, trusted update. Verifying the integrity of every artifact in your build and deployment pipeline is a supply chain security requirement, not an edge case.

A09: Security Logging and Monitoring Failures

The average time to detect a breach is measured in months. Most organizations that discover they were breached do so because an external party notifies them, not because their own monitoring caught the intrusion. Insufficient logging and monitoring is the reason.

Effective security monitoring requires logging authentication events (successes and failures), access control failures, and high-value transaction events; storing logs in a tamper-resistant location; and alerting on anomalous patterns rather than just known attack signatures. Healthcare applications additionally require audit logging of all PHI access to satisfy HIPAA requirements.

A10: Server-Side Request Forgery (SSRF)

SSRF vulnerabilities allow an attacker to cause the server to make HTTP requests to arbitrary targets, including internal services that are not exposed to the internet. In cloud environments, SSRF attacks frequently target the instance metadata service — an internal endpoint accessible from every cloud instance that can return IAM credentials.

SSRF is particularly dangerous in AI applications that fetch external content (web scrapers, URL preview features, webhook receivers) because the attack surface is wide and the exploitability of internal metadata endpoints is high. Allowlisting permitted URL schemes and destinations, validating resolved IP addresses against private ranges, and using separate network segments for outbound requests are the recommended controls.

Using the OWASP Top 10 in Your Engineering Process

The most effective use of the OWASP Top 10 is as a code review checklist. Each category maps to specific code patterns that reviewers can look for. Teams that integrate OWASP categories into their pull request review process catch a substantial fraction of vulnerabilities before they reach production.

Automated static analysis tools can detect a subset of OWASP Top 10 vulnerabilities reliably — injection patterns, hardcoded secrets, and some cryptographic failures lend themselves well to automated detection. Business logic flaws in access control and insecure design require human review that understands application context.

A quarterly code security audit that systematically examines each OWASP category in your codebase provides the comprehensive coverage that neither manual review nor automated scanning delivers alone.