OWASP Top 10 Explained: The Most Critical Web Application Security Risks

The OWASP Top 10 is the most widely recognized list of critical web application security risks. First published in 2003 and updated regularly, it serves as both a security education framework and a minimum baseline for application security programs worldwide.

This guide breaks down each category, explains how attackers exploit these vulnerabilities, and provides practical defense strategies.

What is OWASP?

The Open Web Application Security Project (OWASP) is a nonprofit foundation dedicated to improving software security. Their Top 10 list is compiled from data contributed by hundreds of organizations and security researchers, representing real-world attack patterns affecting real applications.

The OWASP Top 10 is not a compliance checklist. It is a starting point for a security conversation — the minimum set of risks every development team should understand and address.

A01: Broken Access Control

Broken access control is now the #1 risk, appearing in 94% of applications tested. It occurs when users can act outside their intended permissions.

How attackers exploit it:

• Modifying URL parameters to access other users' records (/api/orders?user_id=1234)
• Accessing administrative interfaces without proper authentication
• Elevation of privilege by tampering with JWT tokens or cookies

Defense strategies:

• Enforce access control server-side — never trust client-supplied identity
• Default to deny — explicitly grant, never assume
• Log access control failures and alert on suspicious patterns
• Use ownership checks, not just role checks

// Vulnerable
app.get('/api/orders/:id', async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order); // Anyone can read any order
});

// Secure
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findOne({
    _id: req.params.id,
    userId: req.user.id // Ownership check
  });
  if (!order) return res.status(404).json({ error: 'Not found' });
  res.json(order);
});

A02: Cryptographic Failures

Formerly "Sensitive Data Exposure," this category covers failures related to cryptography that lead to exposure of sensitive data. This includes weak algorithms, missing encryption, and improper key management.

Common failure patterns:

• Passwords stored in plain text or with weak hashing (MD5, SHA1)
• Sensitive data transmitted over HTTP instead of HTTPS
• Weak or hardcoded encryption keys
• Deprecated cryptographic functions (DES, RC4)

Defense strategies:

• Use Argon2, bcrypt, or scrypt for password hashing — never MD5/SHA1
• Enforce HTTPS everywhere with HSTS headers
• Encrypt sensitive data at rest using AES-256 or ChaCha20
• Rotate cryptographic keys and store them outside application code

A03: Injection

Injection attacks occur when untrusted data is sent to an interpreter as part of a command or query. SQL injection is the most well-known, but the category includes command injection, LDAP injection, and more.

SQL injection example:

-- User input: ' OR '1'='1
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''
-- Returns all users — authentication bypassed

Defense strategies:

• Use parameterized queries or prepared statements — always
• Implement input validation and allowlist-based sanitization
• Use an ORM that handles escaping (but verify it does — ORMs have been bypassed)
• Apply least privilege to database accounts

A04: Insecure Design

A new category in 2021, insecure design refers to risks from missing or ineffective control design — architectural flaws, not implementation bugs. No amount of perfect code can fix a fundamentally insecure design.

Examples:

• Password reset flows that leak the reset token in the response
• Multi-tenancy implemented with URL-based tenant isolation only
• Business logic that allows negative values in monetary fields

Defense strategies:

• Threat model during design, not after deployment
• Use security user stories alongside functional ones
• Establish secure design patterns and reference architectures
• Review designs with security-specific questions before writing code

A05: Security Misconfiguration

The most commonly found issue — applications are often deployed with insecure defaults, unnecessary features enabled, or cloud storage misconfigured.

Common misconfigurations:

• Default credentials unchanged (admin/admin on database consoles)
• Verbose error messages exposing stack traces in production
• Publicly accessible cloud storage buckets
• Missing security headers (CSP, X-Frame-Options, HSTS)
• Directory listing enabled on web servers

Defense strategies:

• Use hardened, minimal base images and configurations
• Automate configuration validation with infrastructure-as-code
• Disable all unnecessary features, ports, and services
• Implement a repeatable hardening process — never manually configure production

A06: Vulnerable and Outdated Components

Using libraries, frameworks, and components with known vulnerabilities. With modern applications depending on hundreds of third-party packages, this attack surface is enormous.

Defense strategies:

• Maintain a software bill of materials (SBOM) for every application
• Automate dependency scanning in CI/CD (Dependabot, Snyk, or Mythos)
• Subscribe to vulnerability feeds for your critical dependencies
• Have a defined patch SLA — critical CVEs should be addressed within 24-72 hours

A07: Identification and Authentication Failures

Weaknesses in authentication systems that allow attackers to compromise passwords, session tokens, or authentication processes.

Common failures:

• Permitting credential stuffing without rate limiting or lockout
• Allowing weak or default passwords
• Storing session identifiers in URLs
• Not invalidating sessions after logout

Defense strategies:

• Implement multi-factor authentication for all privileged operations
• Use secure session management — generate cryptographically random tokens
• Enforce account lockout with exponential backoff after failed attempts
• Expire and invalidate sessions on logout, privilege change, and timeout

A08: Software and Data Integrity Failures

This category covers code and infrastructure that does not protect against integrity violations — insecure deserialization, CI/CD pipeline attacks, and auto-update systems that don't verify signatures.

Defense strategies:

• Verify integrity of all downloaded artifacts (checksums, digital signatures)
• Secure your CI/CD pipeline as rigorously as production
• Use SLSA or similar supply chain security frameworks
• Avoid deserialization of untrusted data

A09: Security Logging and Monitoring Failures

Without adequate logging and monitoring, breaches go undetected. The average breach detection time is still measured in months — largely because applications don't emit the right signals.

What to log:

• All authentication events (success and failure)
• Access control failures and privilege escalation attempts
• High-value transactions and data exports
• Input validation failures that could indicate probe activity

Defense strategies:

• Ensure logs are tamper-resistant and stored separately from application servers
• Set up alerting for anomalous patterns — not just known-bad signatures
• Test your incident detection capability regularly
• Include correlation IDs to trace requests across distributed systems

A10: Server-Side Request Forgery (SSRF)

SSRF allows an attacker to induce the server-side application to make requests to unintended locations — often to internal services, cloud metadata endpoints, or localhost.

Classic SSRF attack:

# Attacker submits URL to "fetch preview" feature:
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Application fetches it server-side
# Returns AWS IAM credentials to attacker

Defense strategies:

• Validate and sanitize all user-supplied URLs server-side
• Use allowlists, not blocklists, for permitted URL schemes and destinations
• Disable unnecessary HTTP redirects in server-side HTTP clients
• Segregate fetch functionality in a DMZ without access to internal services

Building on the OWASP Top 10

The OWASP Top 10 is a foundation, not a ceiling. Modern applications also face risks from business logic flaws, API-specific attacks (mass assignment, broken object-level authorization), and supply chain threats that extend beyond these ten categories.

Tools like Mythos Scanner automate coverage of the OWASP Top 10 and go further — using AI reasoning to find the logic-level vulnerabilities that pattern-matching scanners miss.

Related reading:

• What is a Vulnerability Scanner?
• AI vs Traditional Vulnerability Scanners
• What is Claude Mythos?