OWASP Top 10 Web Application Security Risks (2025 Edition)

The OWASP Top 10 is the most widely referenced list of critical web application security risks. Published by the Open Web Application Security Project, it's used by developers, security teams, and auditors as a baseline for web application security.

This guide covers each risk, how attackers exploit it, and practical defenses.

A01: Broken Access Control

Most critical risk, up from #5

Access control enforces that users can only access resources and perform actions they're authorized for. Broken access control occurs when these checks are missing, incomplete, or bypassable.

Common vulnerabilities:

• Accessing other users' data by modifying user ID in URL: GET /account?id=1234 → change to ?id=1235
• Accessing admin pages without admin role
• Elevation of privilege (acting as an admin when authenticated as a regular user)
• Missing function-level access control on API endpoints

Defense:

• Deny by default — all access is denied unless explicitly granted
• Enforce access control on the server, not the client
• Log access control failures and alert on high volumes
• Test every endpoint for horizontal and vertical privilege escalation

A02: Cryptographic Failures

Previously "Sensitive Data Exposure"

Failure to properly protect sensitive data in transit and at rest. Often the root cause of data breaches.

Common vulnerabilities:

• Transmitting sensitive data over HTTP instead of HTTPS
• Using weak encryption (MD5, SHA-1 for passwords, DES/3DES for data)
• Hard-coded encryption keys
• Storing unnecessary sensitive data
• Not enforcing TLS (no HSTS)

Defense:

• Encrypt all sensitive data at rest (AES-256) and in transit (TLS 1.2+)
• Hash passwords with bcrypt, scrypt, or Argon2 (never MD5/SHA)
• Enforce HSTS; disable HTTP
• Don't store data you don't need

A03: Injection

Includes SQL, NoSQL, OS, LDAP injection

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The interpreter executes the attacker-controlled data as commands.

SQL Injection example:

-- Vulnerable query
SELECT * FROM users WHERE email = '" + userInput + "'";

-- Attacker input: ' OR '1'='1
-- Resulting query: SELECT * FROM users WHERE email = '' OR '1'='1'
-- Returns all users

Defense:

• Use parameterized queries / prepared statements exclusively
• Validate and sanitize all input
• Use ORMs (they parameterize by default, though not always safely)
• Apply least privilege to database accounts

Safe example (Node.js with parameterized query):

// ✅ Safe
const result = await db.query(
  'SELECT * FROM users WHERE email = $1',
  [userInput]
);

// ❌ Unsafe
const result = await db.query(
  `SELECT * FROM users WHERE email = '${userInput}'`
);

A04: Insecure Design

New in 2021 — addresses architectural flaws

Security must be designed in from the start, not bolted on. Insecure design refers to missing or ineffective control design, not implementation bugs.

Examples:

• No rate limiting on authentication endpoints (enables brute force)
• Credential recovery that reveals whether an account exists
• Business logic flaws (e.g., negative quantities in e-commerce)

Defense:

• Threat model your application during design
• Follow security design principles (least privilege, defense in depth, fail securely)
• Use established security patterns and frameworks

A05: Security Misconfiguration

Up from #6; includes XXE

The most commonly seen issue. Happens when security is not properly configured at any level: application, framework, server, database, cloud.

Common examples:

• Default credentials unchanged
• Unnecessary features enabled (debug mode in production, unnecessary ports open)
• Overly permissive CORS (Access-Control-Allow-Origin: *)
• Detailed error messages exposing stack traces
• Missing security headers
• S3 buckets publicly accessible

Defense:

• Disable/remove everything not needed
• Automated configuration scanning in CI/CD
• Identical configurations across dev/staging/prod (no "relaxed" settings in production)
• Regular configuration audits

A06: Vulnerable and Outdated Components

Previously "Using Components with Known Vulnerabilities"

Using components (libraries, frameworks, OS, servers) with known unpatched vulnerabilities.

Defense:

• Audit dependencies regularly: npm audit, pip check, Dependabot
• Remove unused dependencies
• Monitor CVE feeds for components you use
• Set up automated dependency updates (Dependabot, Renovate)

# Check for known vulnerabilities
npm audit
npm audit --fix  # Auto-fix where possible

# Or with Snyk
npx snyk test

A07: Identification and Authentication Failures

Previously "Broken Authentication"

Failures in proving who a user is.

Common vulnerabilities:

• Weak passwords allowed
• Missing brute-force protection
• Weak credential recovery (security questions, email-only)
• Session IDs in URLs
• Sessions not invalidated on logout
• Missing MFA

Defense:

• Implement MFA — especially for privileged accounts
• Rate limit authentication attempts
• Use secure session management (HttpOnly, Secure, SameSite cookies)
• Invalidate sessions on logout and password change
• Check passwords against known-breached password lists (HaveIBeenPwned API)

A08: Software and Data Integrity Failures

New in 2021 — includes insecure deserialization

Assumptions about software updates, critical data, and CI/CD pipelines without verifying integrity.

Examples:

• Unsigned software updates
• Insecure deserialization (processing untrusted serialized data)
• Compromised dependencies (supply chain attacks like the SolarWinds attack)

Defense:

• Use digital signatures for software and updates
• Verify integrity of dependencies (lock files, SRI hashes)
• Review CI/CD pipeline security
• Never deserialize data from untrusted sources

A09: Security Logging and Monitoring Failures

Security events aren't logged, or logs aren't monitored. The average time to detect a breach is 207 days — largely because logging is inadequate.

What to log:

• All authentication events (success and failure)
• Access control failures
• Input validation failures
• Administrative actions
• Session management events

Defense:

• Log in a structured format (JSON) to a centralized SIEM
• Alert on anomalies (login failures, access control violations, unusual data access)
• Protect logs from tampering
• Define and test incident response procedures

A10: Server-Side Request Forgery (SSRF)

New in 2021

SSRF occurs when an application fetches a remote resource based on user-supplied input, allowing attackers to make requests from the server to internal resources.

Attack scenario: An application fetches a URL provided by the user (POST /fetch?url=...). The attacker supplies http://169.254.169.254/latest/meta-data/ — the AWS metadata endpoint — and receives IAM credentials.

Defense:

• Validate and sanitize all user-supplied URLs
• Whitelist allowed URL schemes and destinations
• Don't forward responses from internal resources to users
• Block requests to metadata endpoints (169.254.169.254, fd00:ec2::254)
• Use a dedicated outbound proxy that enforces allowlists