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 — the eighth installment of the project — drew on data contributed for over 2.8 million applications, analyzed 589 distinct CWEs in the source dataset, and finalized 248 CWEs distributed across the 10 published categories, with a hard cap of 40 CWEs per category. The result is the de-facto industry baseline for application security priorities.¹

Abstract

OWASP Top 10:2025 is “data-informed, but not blindly data-driven”: eight categories were ranked from contributed application-test data, the remaining two (Software Supply Chain Failures and Security Logging & Alerting Failures) were promoted by a community survey because the available data systematically under-represents them.¹ The 2025 cut introduced two new categories (A03 Software Supply Chain Failures, A10 Mishandling of Exceptional Conditions), consolidated SSRF into Broken Access Control, and elevated Security Misconfiguration to #2 because 100% of tested applications had at least one misconfiguration CWE present.²

Core mental model:

Why the rankings shift. OWASP scopes a category by grouping CWEs into a root-cause bucket, then ranks by an exploitability + impact score weighted by incidence rate. Position changes between editions reflect both real industry shifts and OWASP’s deliberate move from symptom-led categories (“Sensitive Data Exposure”) to root-cause categories (“Cryptographic Failures”) begun in 2021.¹

What changed since 2021

A01: Broken Access Control

Broken Access Control retains the #1 slot. Across the contributed data, 100% of applications tested had at least one access-control CWE present. The category covers 40 CWEs, 1,839,701 occurrences, and 32,654 CVEs — by far the largest CVE population of any category.³ Server-Side Request Forgery (SSRF, CWE-918) was folded in because forging requests to internal resources is, mechanically, an authorization bypass.

Vulnerability patterns

Prevention

Show 4 hidden lines5export function authorize(resource: string, action: string) {6  return async (req: Request, res: Response, next: NextFunction) => {7    const token = req.headers.authorization?.split(" ")[1]8    if (!token) return res.status(401).json({ error: "No token" })910    const payload = verify(token, process.env.JWT_SECRET!)11    const allowed = await hasPermission(payload.sub, resource, action)1213    if (!allowed) return res.status(403).json({ error: "Forbidden" })14    next()15  }16}17Show 3 hidden lines

The non-negotiable controls per OWASP A01 guidance:³

1. Deny by default — explicit grants for every resource.
2. Server-side enforcement — never trust client-side state.
3. Record-ownership validation — verify the requesting principal owns the row, not just that they can call the endpoint.
4. Centralized access control — one module, one place to audit.
5. Short-lived JWTs / revoke-on-logout sessions — invalidate stateful sessions server-side; keep stateless tokens short with refresh-token rotation.
6. Rate limit controller and API access to slow automated tooling.

SSRF-specific prevention

Show 5 hidden lines67async function fetchSafely(userUrl: string): Promise<Response> {8  const url = new URL(userUrl)910  if (url.protocol !== "https:") throw new Error("Only HTTPS allowed")11  if (!ALLOWED_HOSTS.has(url.hostname)) throw new Error("Host not on allowlist")1213  // DNS rebinding protection: resolve once, validate every address, then fetch.14  const addresses = await dns.resolve4(url.hostname)15  for (const addr of addresses) {16    const parsed = ipaddr.parse(addr)17    if (parsed.range() !== "unicast") throw new Error("Private IP not allowed")18  }19Show 2 hidden lines

A02: Security Misconfiguration

Security Misconfiguration jumped from #5 to #2. 100% of tested applications had at least one misconfiguration CWE, with a max incidence rate of 27.70%, average 3.00%, ~719k occurrences, and 16 mapped CWEs.² XML External Entities (XXE, CWE-611) stays consolidated here — it is fundamentally a parser misconfiguration, not a separate vulnerability class.

Common misconfigurations

Security headers

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload2X-Content-Type-Options: nosniff3X-Frame-Options: DENY4Referrer-Policy: strict-origin-when-cross-origin5Permissions-Policy: geolocation=(), microphone=(), camera=()6Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}';

Configuration hardening

Show 2 hidden lines3// fast-xml-parser is a pure-JS parser and does NOT resolve external DTD entities,4// so the classic file-disclosure XXE is not reachable here. The flags below stay5// conservative anyway and document intent. For DOM/SAX parsers backed by6// libxml2/Xerces, you MUST also disable DOCTYPE / external entity loading7// explicitly — that is where most real-world XXE bugs live.8const parser = new XMLParser({9  ignoreAttributes: false,10  processEntities: false,11  htmlEntities: false,12})

The OWASP A02 hardening workflow:²

1. Repeatable hardening — automated, identical environments differing only in secrets.
2. Minimal install — drop sample apps, docs, unused features and frameworks.
3. Automated config verification — config checks in CI, drift detection in production.
4. Short-lived credentials — identity federation (OIDC, SPIFFE) over hardcoded secrets in code or pipelines.
5. Cloud IAM and firewall audits — at least annually if not continuous.

A03: Software Supply Chain Failures

New in 2025, A03 is the renamed and expanded successor to A06:2021 Vulnerable and Outdated Components. It absorbed every supply-chain failure mode, not just outdated dependencies. The community survey ranked it #1 — exactly 50% of respondents put it first — because the contributed data underrepresents an obviously growing risk class. The category page lists 6 mapped CWEs but surfaces only 11 CVEs in the dataset, while still recording the highest average incidence rate of any 2025 category at 5.72%.⁴

Why it was added

Three incidents shaped the new category:

• SolarWinds (2019) — a build-system compromise in the Orion product cascaded into roughly 18,000 organizations via signed but malicious updates.⁴
• Log4Shell (CVE-2021-44228) — a single Apache Log4j JNDI lookup CVE put an enormous fraction of Java services at risk overnight, and remained the textbook supply-chain CVE for years.⁴
• Shai-Hulud (2025) — the first successful self-propagating npm worm. Compromised packages ran a post-install script that exfiltrated tokens to public GitHub repositories and then used any harvested npm tokens to publish malicious versions of additional packages, reaching 500+ package versions before npm disrupted it.⁴

Supply chain risk vectors

Dependency management

Show 5 hidden lines6    "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  }Show 1 hidden line

Supply-chain hygiene per the OWASP A03 prevention list:⁴

1. SBOM — generate with CycloneDX or SPDX and diff it on every release.
2. Continuous scanning — OWASP Dependency-Check / Dependency-Track, npm audit, Snyk, GitHub Dependabot, all in CI.
3. Lockfile discipline — pin versions; review transitive bumps deliberately rather than letting ^ ranges float in production.
4. Private proxy registry — proxy public packages, scan before allowing, and block direct internet pulls from build runners.
5. Subresource Integrity (SRI) for any third-party browser asset:

1<script2  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. Treat SRI hashes as another lockfile.

6. Staged rollouts for both your code and dependency upgrades — never ship a fleet-wide major bump on day zero of release.

A04: Cryptographic Failures

Cryptographic Failures fell from #2 to #4. The category covers 32 mapped CWEs, ~1.66M occurrences, and 2,185 CVEs. It targets root causes (broken algorithms, weak keys, predictable PRNGs, missing authenticated encryption) rather than the symptom of data exposure.⁹

Vulnerability patterns

Password storage

Show 3 hidden lines4// Tune so your hardware lands at ~250-500ms per hash.5const PASSWORD_OPTIONS = {6  type: 2, // argon2id (hybrid: side-channel + time-memory tradeoff resistant)7  memoryCost: 65536, // 64 MiB8  timeCost: 3,9  parallelism: 4,10}1112export async function hashPassword(password: string): Promise<string> {13  return hash(password, PASSWORD_OPTIONS)14}1516export async function verifyPassword(password: string, stored: string): Promise<boolean> {17  return verify(stored, password)18}

Why Argon2id. It is the OWASP Password Storage Cheat Sheet primary recommendation for new systems. Memory-hardness defeats GPU/ASIC cracking; the id variant combines Argon2i’s side-channel resistance with Argon2d’s time-memory-tradeoff resistance. OWASP’s minimum parameters are m=19 MiB, t=2, p=1; the example above is well above that floor and is appropriate for typical server hardware.

Data classification workflow

1. Identify sensitive data per PCI DSS, GDPR, HIPAA.
2. Encrypt at rest with AES-256-GCM (authenticated) or equivalent.
3. Encrypt in transit with TLS 1.2+ (TLS 1.3 preferred), forward-secrecy ciphers, no CBC.
4. Manage keys in an HSM or cloud KMS — never in source.
5. Rotate keys on schedule and immediately on suspected compromise.

A05: Injection

Injection fell from #3 to #5 but is still hugely consequential: 37 mapped CWEs, 1.4M occurrences, and 62,445 CVEs — the most CVEs of any 2025 category. The CVE volume is dominated by Cross-Site Scripting (CWE-79, >30k CVEs) and SQL Injection (>14k CVEs).¹⁰ XSS stays consolidated here — it is HTML/JavaScript injection.

Attack surface

SQL injection prevention

Show 3 hidden lines45// VULNERABLE: string concatenation.6async function getUserUnsafe(id: string) {7  // Attacker payload: "1; DROP TABLE accounts;--"8  return pool.query(`SELECT * FROM accounts WHERE id = ${id}`)9}1011// SAFE: parameterized query.12async function getUserSafe(id: string) {13  return pool.query("SELECT * FROM accounts WHERE id = $1", [id])14}1516// SAFE: ORM with typed parameters.17async function getUserORM(id: number) {Show 2 hidden lines

Content Security Policy

CSP is the primary defense-in-depth control for XSS — it tells the browser which sources are allowed to execute script:

1Content-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';

Deploy in two phases: ship Content-Security-Policy-Report-Only first, analyze violation reports, then enforce. Treat any inline-script violation as a refactor, not as a CSP exception.

A06: Insecure Design

Insecure Design fell from #4 to #6 — not because design failures got rarer but because Misconfiguration and Supply Chain leapfrogged it. It still spans 39 CWEs, ~730k occurrences, and 7,647 CVEs.¹¹ The category targets architectural flaws that cannot be fixed by secure implementation — an insecure design cannot be saved by perfect code.

Design vs implementation

Prevention

1. Secure development lifecycle with threat modeling on the critical flows, not the whole app.
2. Security requirements written into user stories so they ship with the feature, not after.
3. A paved-road library of authentication, authorization, and session patterns — opt out by exception, not by default.
4. Plausibility checks at every tier (can a user really order 10,000 items? buy 600 cinema seats?).
5. Rate limits on expensive operations.

Example: the cinema chain group-booking attack

OWASP’s canonical Insecure Design scenario: a cinema chain offers group-booking discounts and only requires a deposit beyond fifteen attendees. An attacker threat-models the flow and books 600 seats across multiple cinemas in a few requests, blocking real customers and never paying.¹¹ The fix is design-level: cap concurrent un-deposited holds, require escalating deposits past a threshold, and bot-detect the request pattern.

A07: Authentication Failures

Authentication Failures keeps #7 with 36 mapped CWEs, ~1.12M occurrences, and 7,147 CVEs. The name shortened from “Identification and Authentication Failures” to focus the category on authentication-specific weaknesses. OWASP attributes the lack of upward movement to wider use of standardized identity frameworks.⁶

Vulnerability patterns

Session management

Show 5 hidden lines67app.use(8  session({9    store: new RedisStore({ client: redisClient }),10    secret: process.env.SESSION_SECRET!,11    name: "__Host-session", // __Host- prefix forces Secure, Path=/, no Domain12    resave: false,13    saveUninitialized: false,14    cookie: {15      secure: true,16      httpOnly: true,17      sameSite: "strict",18      maxAge: 15 * 60 * 1000, // 15 minutes19    },20  }),21)Show 7 hidden lines29  })30})

NIST SP 800-63B password guidance

NIST SP 800-63B reversed decades of password theater. OWASP A07 endorses the same guidance:⁶

• No composition rules — forced symbols make passwords worse, not better.
• No periodic rotation — change only on evidence of compromise.
• Minimum 8 characters (12+ in practice), maximum at least 64.
• Check against breached password lists — integrate something like the Have I Been Pwned Pwned Passwords k-anonymity API.
• Allow paste — password managers are the actual primary defense.
• MFA wherever possible — preferably a phishing-resistant factor (WebAuthn / passkeys) rather than SMS.

A08: Software or Data Integrity Failures

A08 stays at #8 with a clarifying name change (“and” → “or”). It covers 14 CWEs, ~501k occurrences, and 3,331 CVEs. The line OWASP draws between A03 and A08: A03 covers the supply chain producing the artifact, A08 covers your runtime trusting an artifact or data blob without verifying it (auto-update, deserialization, cookie integrity).⁷

Integrity patterns

Deserialization safety

Show 3 hidden lines4const schema = {5  type: "object",6  properties: {7    userId: { type: "integer" },8    action: { type: "string", enum: ["read", "write"] },9  },10  required: ["userId", "action"],11  additionalProperties: false,12}1314const validate = ajv.compile(schema)1516function processInput(untrusted: string) {17  const data = JSON.parse(untrusted)18  if (!validate(data)) throw new Error("Invalid input schema")19  // Now safe to use data.userId, data.action.20}

CI/CD integrity controls

1. Signed commits on protected branches.
2. Reproducible / hermetic builds — same source ⇒ same binary, ideally with SLSA provenance.
3. Artifact signing — verify before deployment.
4. Least-privilege runners — short-lived, scoped credentials per job; no persistent admin tokens.
5. Secret scanning — block credentials in logs and artifacts.

A09: Security Logging & Alerting Failures

A09 keeps #9 with the deliberate rename from “Security Logging and Monitoring Failures”: alerting is the verb that matters. The category has only 5 mapped CWEs and 723 CVEs because it is hard to detect via static testing — it returned through the community survey for the third time.⁸ As a calibration point, the IBM Cost of a Data Breach 2025 report puts the global mean time to identify and contain a breach at 241 days, the lowest in nine years and still measured in hundreds of days.¹²

What to log

Log injection prevention

Show 3 hidden lines4  formatters: { level: (label) => ({ level: label }) },5})67// SAFE: structured logging, attacker-controlled values are values, not formatting.8logger.info({ userId: user.id, action: "login" }, "User authenticated")910// UNSAFE: user input concatenated into the log string enables injection.11// logger.info(`User ${username} logged in`)12// username = "admin\n[ALERT] Breach"

Alerting strategy

1. Real-time alerts for auth failures, privilege changes, sensitive-resource access.
2. Anomaly detection for unusual access patterns (high false-positive rate; treat as a secondary signal).
3. Tamper-evident storage for logs — append-only sinks, separate retention boundary.
4. Incident response playbook per NIST SP 800-61r2 (or the in-progress r3 once finalized).
5. Periodic drill — purple-team exercises validate that detection actually fires.

A10: Mishandling of Exceptional Conditions

New in 2025 and replacing what used to be a vague “code quality” bucket. A10 covers 24 mapped CWEs, ~770k occurrences, and 3,416 CVEs. It addresses failures to prevent, detect, or respond to abnormal states — crashes, fail-open conditions, partial transactions.⁵

Failure modes

Prevention

Show 3 hidden lines4  const t = await sequelize.transaction()5  try {6    await Account.decrement("balance", { by: amount, where: { id: from }, transaction: t })7    await Account.increment("balance", { by: amount, where: { id: to }, transaction: t })8    await t.commit()9  } catch (error) {10    await t.rollback() // Fail closed: no partial state survives.11    logger.error({ from, to, amount, err: error.message }, "Transfer failed")12    throw new Error("Transfer failed") // Don't leak internals.13  }14}

The OWASP A10 control surface:⁵

1. Local handling at the point of failure — meaningful recovery beats a top-level catch-all.
2. Global exception handler as a safety net, never as the primary strategy.
3. Fail closed — transactional rollback, deny on error, never partial state.
4. Resource quotas — rate limits, memory caps, connection caps.
5. Sanitized error messages — no stack traces, no internal paths, no DB metadata back to users.

Conclusion

The OWASP Top 10:2025 is the clearest articulation yet of the modern AppSec baseline:

1. Access control is still #1 — every endpoint is an authorization decision. SSRF is now part of this category.
2. Misconfiguration is the new #2 — secure defaults are still rare; cloud and IaC make misconfigurations reproducible at scale.
3. Supply chain is unavoidable — the new A03 reflects SolarWinds, Log4Shell, and self-propagating npm worms. Spend on SBOM, signing, and provenance.
4. Mishandling exceptional conditions joins the list — fail-closed, transactional rollback, and bounded resources are now first-class controls.
5. Detection enables response — logging without alerting is forensic dust; if your pages don’t fire, your detection doesn’t exist.

Use the Top 10 as a baseline for threat modeling, code-review checklists, and security testing. For high-assurance systems, escalate to the OWASP Application Security Verification Standard (ASVS), which covers the same ground at far greater depth.

Appendix

Prerequisites

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

Summary

• A01–A02 (Access Control, Misconfiguration): deny by default, secure defaults, cloud IAM hygiene.
• A03–A04 (Supply Chain, Crypto): verify dependencies, modern algorithms, prepare for PQC by 2030.
• A05–A06 (Injection, Design): parameterized APIs, threat modeling on the critical flows.
• A07–A08 (Auth, Integrity): MFA, breach-list checks, signed updates, no untrusted deserialization.
• A09–A10 (Logging & Alerting, Exceptional Conditions): centralized alerting, fail closed.
• 2025 added Software Supply Chain Failures and Mishandling of Exceptional Conditions; SSRF moved into A01.

References

• OWASP Top 10:2025 — official project landing page.
• Introduction — OWASP Top 10:2025 — methodology, dataset, and what changed.
• 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, language-agnostic.
• NIST SP 800-63B Digital Identity Guidelines — authentication requirements.
• NIST SP 800-61r2 Computer Security Incident Handling Guide — incident response.
• RFC 6749 OAuth 2.0 and OAuth 2.1 draft — authorization framework.
• RFC 8446 TLS 1.3 — transport security.
• SLSA — Supply-chain Levels for Software Artifacts — build-integrity framework.