OWASP Top 10: Web Application Security Risks

The OWASP Top 10 is a ranked list of the most critical web application security risks, derived from real-world vulnerability data. The 2025 edition analyzed 2.8 million applications with 589 CWE (Common Weakness Enumeration) mappings across 248 categories, making it the definitive baseline for application security priorities.

Abstract

The OWASP Top 10 represents a data-driven consensus on application security priorities. The 2025 edition introduced two new categories (Software Supply Chain Failures, Mishandling of Exceptional Conditions), consolidated SSRF (Server-Side Request Forgery) into Broken Access Control, and elevated Security Misconfiguration to #2 based on 100% incidence rates.

Core mental model:

Key shift in 2025: Security Misconfiguration rose from #5 to #2, reflecting that 100% of tested applications had some form of misconfiguration. Supply chain attacks (SolarWinds, Log4Shell, npm worms) drove the addition of a dedicated category.

Version history: The 2021 edition introduced root-cause categorization (e.g., “Cryptographic Failures” instead of “Sensitive Data Exposure”). The 2025 edition expanded scope from ~400 to 589 CWEs and added community-driven categories for emerging threats.

A01: Broken Access Control

Broken Access Control maintains #1 with 100% of applications tested showing some vulnerability. With 40 mapped CWEs, 1.8M+ occurrences, and 32,654 CVEs, it’s the most prevalent risk. SSRF was consolidated into this category since it fundamentally bypasses access boundaries.

Why It’s #1

Access control enforces policy so users cannot act outside their intended permissions. API-first architectures expanded attack surface—every endpoint is a potential authorization decision point. The consolidation of SSRF acknowledges that forging requests to internal resources is an access control bypass.

Vulnerability Patterns

Prevention

4 collapsed lines
1
import { Request, Response, NextFunction } from "express"
2
import { verify } from "jsonwebtoken"
3
import { hasPermission } from "./rbac"
4

5
// Middleware: deny-by-default, explicit allow
6
export function authorize(resource: string, action: string) {
7
  return async (req: Request, res: Response, next: NextFunction) => {
8
    const token = req.headers.authorization?.split(" ")[1]
9
    if (!token) return res.status(401).json({ error: "No token" })
10

11
    const payload = verify(token, process.env.JWT_SECRET!)
12
    const allowed = await hasPermission(payload.sub, resource, action)
13

14
    if (!allowed) return res.status(403).json({ error: "Forbidden" })
15
    next()
16
  }
17
}
5 collapsed lines
18

19
// Route: explicit authorization on every endpoint
20
app.get("/api/users/:id", authorize("users", "read"), getUser)
21
app.put("/api/users/:id", authorize("users", "update"), updateUser)
22
app.delete("/api/users/:id", authorize("users", "delete"), deleteUser)

Critical controls:

1. Deny by default—require explicit grants for every resource
2. Server-side enforcement—never trust client-side state
3. Record ownership validation—verify the requesting user owns the resource
4. Centralized access control—one module, consistent enforcement
5. SSRF prevention—allowlist outbound destinations, validate resolved IPs
6. Rate limiting—slow automated attacks

SSRF-Specific Prevention

5 collapsed lines
1
import { URL } from "url"
2
import dns from "dns/promises"
3
import ipaddr from "ipaddr.js"
4

5
const ALLOWED_HOSTS = ["api.example.com", "cdn.example.com"]
6

7
async function fetchSafely(userUrl: string): Promise<Response> {
8
  const url = new URL(userUrl)
9

10
  // Protocol allowlist (no file://, gopher://, etc.)
11
  if (!["https:"].includes(url.protocol)) {
12
    throw new Error("Only HTTPS allowed")
13
  }
14

15
  // DNS rebinding protection: resolve and check before fetch
16
  const addresses = await dns.resolve4(url.hostname)
17
  for (const addr of addresses) {
18
    const parsed = ipaddr.parse(addr)
19
    if (parsed.range() !== "unicast") {
6 collapsed lines
20
      throw new Error("Private IP not allowed")
21
    }
22
  }
23

24
  return fetch(url.toString(), { redirect: "error" })
25
}

Network controls: Disable cloud metadata endpoints (IMDSv2 or block 169.254.169.254), segment internal services from web tier.

A02: Security Misconfiguration

Security Misconfiguration rose from #5 (2021) to #2 (2025), with 100% of tested applications showing some misconfiguration. The 27.70% max incidence rate and 16 mapped CWEs reflect that secure defaults are rare, and every stack layer can be misconfigured.

Why It Rose

Cloud infrastructure complexity multiplied configuration surfaces. XXE (XML External Entities) remains consolidated here—it’s fundamentally a parser misconfiguration. The shift to infrastructure-as-code made misconfigurations reproducible at scale.

Common Misconfigurations

Security Headers

1
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
2
X-Content-Type-Options: nosniff
3
X-Frame-Options: DENY
4
Referrer-Policy: strict-origin-when-cross-origin
5
Permissions-Policy: geolocation=(), microphone=(), camera=()
6
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}';

Configuration Hardening

2 collapsed lines
1
import { XMLParser } from "fast-xml-parser"
2

3
// SAFE: external entities disabled (default in modern parsers)
4
const parser = new XMLParser({
5
  ignoreAttributes: false,
6
  // These enable XXE - never enable without explicit need:
7
  // processEntities: true,
8
  // allowBooleanAttributes: true,
9
})

Hardening workflow:

1. Minimal installation—remove sample apps, documentation, unused features
2. Identical environments—dev/staging/prod differ only in secrets
3. Automated verification—config checks in CI/CD pipeline
4. Short-lived credentials—identity federation, not hardcoded secrets
5. Regular audits—quarterly review of cloud IAM, firewall rules

A03: Software Supply Chain Failures

New in 2025, Software Supply Chain Failures expanded from “Vulnerable and Outdated Components” to address the entire software supply chain. It ranked #1 in community surveys (50% of respondents), with a 5.72% average incidence rate—the highest of any category.

Why It Was Added

SolarWinds (18,000+ organizations compromised), Log4Shell (CVE-2021-44228 affecting millions of systems), and Shai-Hulud (2025’s first self-propagating npm worm harvesting tokens and auto-propagating to 500+ package versions) demonstrated that supply chain attacks scale catastrophically. Your application is only as secure as its least secure dependency.

Supply Chain Risk Vectors

Dependency Management

5 collapsed lines
1
{
2
  "name": "secure-app",
3
  "version": "1.0.0",
4
  "scripts": {
5
    "audit": "npm audit --production",
6
    "audit:fix": "npm audit fix",
7
    "sbom": "npx @cyclonedx/cyclonedx-npm --output-file sbom.json"
8
  },
9
  "dependencies": {
10
    "express": "^4.18.2"
11
  },
12
  "overrides": {
13
    "lodash": "4.17.21"
14
  }
1 collapsed line
15
}

Supply chain hygiene:

1. SBOM (Software Bill of Materials)—generate with CycloneDX or SPDX
2. Automated scanning—OWASP Dependency-Check, Snyk, npm audit in CI
3. Version pinning—lock files, avoid floating versions in production
4. Private registry—proxy public packages, scan before allowing
5. SRI (Subresource Integrity)—hash verification for CDN scripts
6. Staged rollouts—canary deployments, not simultaneous updates

SRI Example

1
<script
2
  src="https://cdn.example.com/lib.js"
3
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
4
  crossorigin="anonymous"
5
></script>

If the CDN script changes, the browser refuses execution.

A04: Cryptographic Failures

Cryptographic Failures moved from #2 (2021) to #4 (2025), with 32 mapped CWEs and 1.6M+ occurrences. The category focuses on root causes—broken algorithms, weak keys, insufficient entropy—rather than the symptom of data exposure.

Vulnerability Patterns

Password Storage

3 collapsed lines
1
import { hash, verify } from "argon2"
2

3
// Argon2id: OWASP-recommended for password hashing
4
const PASSWORD_OPTIONS = {
5
  type: 2, // argon2id (hybrid: side-channel + time-memory tradeoff resistant)
6
  memoryCost: 65536, // 64MB
7
  timeCost: 3,
8
  parallelism: 4,
9
}
10

11
export async function hashPassword(password: string): Promise<string> {
12
  return hash(password, PASSWORD_OPTIONS)
13
}
14

15
export async function verifyPassword(password: string, stored: string): Promise<boolean> {
16
  return verify(stored, password)
17
}

Why Argon2id: Memory-hard functions resist GPU/ASIC cracking. Argon2id combines side-channel resistance (Argon2i) with time-memory tradeoff resistance (Argon2d). NIST recommends preparation for post-quantum cryptography by 2030 for high-value systems.

Data Classification

1. Identify sensitive data per PCI-DSS, GDPR, HIPAA
2. Encrypt at rest using AES-256-GCM (authenticated)
3. Encrypt in transit via TLS 1.3 with forward secrecy
4. Key management: HSM or cloud KMS, never in source
5. Rotate keys on schedule and after compromise

A05: Injection

Injection dropped from #3 (2021) to #5 (2025), but remains critical with 37 mapped CWEs, 62,445 CVEs, and 100% of applications showing some vulnerability. XSS (Cross-Site Scripting) remains consolidated here—it’s HTML/JavaScript injection.

Attack Surface

SQL Injection Prevention

3 collapsed lines
1
import { Pool } from "pg"
2

3
const pool = new Pool()
4

5
// VULNERABLE: string concatenation
6
async function getUserUnsafe(id: string) {
7
  // Attacker: "1; DROP TABLE users;--"
8
  return pool.query(`SELECT * FROM accounts WHERE id = ${id}`)
9
}
10

11
// SAFE: parameterized query
12
async function getUserSafe(id: string) {
13
  return pool.query("SELECT * FROM accounts WHERE id = $1", [id])
14
}
15

16
// SAFE: ORM with typed parameters
17
async function getUserORM(id: number) {
2 collapsed lines
18
  return prisma.user.findUnique({ where: { id } })
19
}

Content Security Policy

CSP is the primary XSS defense—it tells browsers which sources can execute scripts:

1
Content-Security-Policy:
2
  default-src 'self';
3
  script-src 'self' 'nonce-abc123';
4
  style-src 'self' 'unsafe-inline';
5
  img-src 'self' data: https:;
6
  connect-src 'self' https://api.example.com;
7
  frame-ancestors 'none';
8
  base-uri 'self';
9
  form-action 'self';

CSP deployment: Start with Content-Security-Policy-Report-Only, analyze violations, then enforce.

A06: Insecure Design

Insecure Design dropped from #4 (2021) to #6 (2025), with 39 mapped CWEs. It targets architectural flaws that cannot be fixed by secure implementation—an insecure design cannot be saved by secure code.

Design vs Implementation

Prevention

1. Secure development lifecycle with threat modeling
2. Security requirements in user stories
3. Design pattern library for authentication, authorization
4. Plausibility checks at all tiers (can one user really order 10,000 items?)
5. Rate limits on expensive operations

Example: Cinema Attack

A cinema allowed unlimited seat reservations. Attackers reserved all seats, preventing legitimate sales, then released them last-minute.

Design fix: Maximum seats per session, escalating hold costs, bot detection.

A07: Authentication Failures

Authentication Failures maintains #7 with 36 mapped CWEs, 1.1M+ occurrences, and 7,147 CVEs. The name shortened from “Identification and Authentication Failures” to emphasize the authentication focus.

Vulnerability Patterns

Session Management

5 collapsed lines
1
import session from "express-session"
2
import RedisStore from "connect-redis"
3
import { createClient } from "redis"
4

5
const redisClient = createClient()
6

7
app.use(
8
  session({
9
    store: new RedisStore({ client: redisClient }),
10
    secret: process.env.SESSION_SECRET!,
11
    name: "__Host-session", // Cookie prefix binding
12
    resave: false,
13
    saveUninitialized: false,
14
    cookie: {
15
      secure: true, // HTTPS only
16
      httpOnly: true, // No JS access
17
      sameSite: "strict", // CSRF protection
18
      maxAge: 15 * 60 * 1000, // 15 minutes
19
    },
20
  }),
21
)
7 collapsed lines
22

23
// Regenerate session on login (prevent fixation)
24
app.post("/login", async (req, res) => {
25
  const user = await authenticate(req.body)
26
  req.session.regenerate(() => {
27
    req.session.userId = user.id
28
    res.json({ success: true })
29
  })
30
})

NIST 800-63B Guidelines

NIST reversed decades of password theater:

• No complexity requirements—users create worse passwords with forced symbols
• No periodic rotation—change only on evidence of compromise
• Minimum 8 characters (12+ recommended), max at least 64
• Check against breached passwords—haveibeenpwned integration
• Allow paste—password managers are the primary defense

A08: Software and Data Integrity Failures

Software and Data Integrity Failures remains #8, addressing assumptions about updates, critical data, and CI/CD pipelines without verifying integrity. Distinct from A03: this category focuses on runtime integrity checks (deserialization, auto-updates), while A03 focuses on supply chain provenance.

Integrity Patterns

Deserialization Safety

3 collapsed lines
1
import Ajv from "ajv"
2

3
// SAFE: schema validation before use
4
const ajv = new Ajv()
5
const schema = {
6
  type: "object",
7
  properties: {
8
    userId: { type: "integer" },
9
    action: { type: "string", enum: ["read", "write"] },
10
  },
11
  required: ["userId", "action"],
12
  additionalProperties: false,
13
}
14

15
const validate = ajv.compile(schema)
16

17
function processInput(untrusted: string) {
18
  const data = JSON.parse(untrusted)
19
  if (!validate(data)) {
20
    throw new Error("Invalid input schema")
21
  }
22
  // Now safe to use data.userId, data.action
23
}

CI/CD Security

1. Signed commits—GPG signatures on protected branches
2. Reproducible builds—same source → same binary
3. Artifact signing—verify packages before deployment
4. Least privilege runners—CI jobs run with minimal permissions
5. Secret scanning—no credentials in logs or artifacts

A09: Logging and Alerting Failures

Renamed from “Security Logging and Monitoring Failures” to emphasize alerting—logging without alerting provides minimal value. With only 5 mapped CWEs, it’s community-driven rather than data-driven, reflecting that breaches averaging 287 days undetected (IBM 2021) demonstrate detection failures.

What to Log

Log Injection Prevention

3 collapsed lines
1
import pino from "pino"
2

3
const logger = pino({
4
  formatters: {
5
    level: (label) => ({ level: label }),
6
  },
7
})
8

9
// SAFE: structured logging (not string concatenation)
10
logger.info({ userId: user.id, action: "login" }, "User authenticated")
11

12
// UNSAFE: user input in log string enables injection
13
// logger.info(`User ${username} logged in`);
14
// username = "admin\n[ALERT] Breach"

Alerting Strategy

1. Real-time alerts for auth failures, privilege changes
2. Anomaly detection for unusual access patterns
3. Tamper-evident storage for logs
4. Incident response playbook per NIST 800-61r2
5. Regular testing of detection capabilities

A10: Mishandling of Exceptional Conditions

New in 2025, this category addresses failures to prevent, detect, and respond to unusual situations—crashes, unexpected behavior, and exploitable states. With 24 mapped CWEs and 3,416 CVEs, it replaces vague “code quality” categories with specific guidance.

Failure Modes

Prevention

3 collapsed lines
1
import { Transaction } from "sequelize"
2

3
// SAFE: transactional rollback on any failure
4
async function transferFunds(from: number, to: number, amount: number) {
5
  const t = await sequelize.transaction()
6
  try {
7
    await Account.decrement("balance", { by: amount, where: { id: from }, transaction: t })
8
    await Account.increment("balance", { by: amount, where: { id: to }, transaction: t })
9
    await t.commit()
10
  } catch (error) {
11
    await t.rollback() // Fail closed: no partial state
12
    logger.error({ from, to, amount, error: error.message }, "Transfer failed")
13
    throw new Error("Transfer failed") // Don't leak internals
14
  }
15
}

Key controls:

1. Local error handling—catch at occurrence point with meaningful recovery
2. Global exception handler—backup for uncaught exceptions
3. Fail closed—transactional rollback, deny access on error
4. Resource quotas—rate limiting, memory limits
5. Sanitized error messages—no stack traces to users

Conclusion

The OWASP Top 10:2025 reflects the evolved threat landscape based on data from 2.8M applications:

1. Access control remains #1—SSRF consolidated here, every endpoint needs explicit authz
2. Misconfiguration rose to #2—100% incidence, secure defaults are rare
3. Supply chain is critical—new category driven by SolarWinds, Log4Shell, npm worms
4. Exception handling matters—new category for fail-closed patterns
5. Detection enables response—logging without alerting is ineffective

Use the Top 10 as a baseline for threat modeling, code review checklists, and security testing. For high-assurance applications, ASVS (Application Security Verification Standard) provides deeper coverage.

Appendix

Prerequisites

• HTTP request/response model
• Web application architecture (client/server, APIs)
• Authentication flows (sessions, tokens)

Summary

• A01-A02 (Access Control, Misconfiguration): Deny-by-default, secure defaults
• A03-A04 (Supply Chain, Crypto): Verify dependencies, use modern algorithms
• A05-A06 (Injection, Design): Parameterized queries, threat modeling
• A07-A08 (Auth, Integrity): MFA, signed artifacts
• A09-A10 (Logging, Exceptions): Centralized alerting, fail-closed
• 2025 added Supply Chain Failures and Mishandling Exceptional Conditions
• SSRF consolidated into Broken Access Control

References

• OWASP Top 10:2025 - Official specification and methodology
• OWASP Top 10:2025 Introduction - Methodology and data sources
• OWASP Application Security Verification Standard (ASVS) - Comprehensive security requirements
• OWASP Cheat Sheet Series - Implementation guidance per category
• CWE Top 25 Most Dangerous Software Weaknesses - Complementary ranking
• NIST SP 800-63B Digital Identity Guidelines - Authentication requirements
• NIST SP 800-61r2 Incident Handling - Logging and response
• RFC 6749 OAuth 2.0 - Authorization framework
• RFC 8446 TLS 1.3 - Transport security