The OWASP Top 10 is the closest thing web security has to a shared vocabulary. Auditors cite it, customers ask about it in security questionnaires, and it shapes what developers learn first. The 2025 edition, published in late 2025, is the first update since 2021, and it reflects how attacks have shifted: from bugs in our own code toward the way software is built, configured and assembled from dependencies. This guide walks through the list, explains what changed, and gives concrete defenses for typical Next.js, Node.js and Java applications.

The list at a glance

Rank Category Change since 2021
A01 Broken Access Control Still #1; now includes server-side request forgery (SSRF)
A02 Security Misconfiguration Up from #5
A03 Software Supply Chain Failures New, expanded from "Vulnerable and Outdated Components"
A04 Cryptographic Failures Down from #2
A05 Injection Down from #3
A06 Insecure Design Down from #4
A07 Authentication Failures Same position, renamed
A08 Software or Data Integrity Failures Same position
A09 Security Logging and Alerting Failures Same position, now emphasizes alerting
A10 Mishandling of Exceptional Conditions New category

The ranking is based on data from more than 2.8 million tested applications contributed by 13 organizations, mapped to 589 CWEs, with two categories promoted by a community survey to capture risks not yet well covered by automated testing (OWASP Top 10:2025).

A01: Broken Access Control

Users acting outside their intended permissions remains the most common serious flaw: viewing another customer's order by changing an ID in the URL, calling admin APIs from a normal account, or tricking the server into fetching internal URLs (SSRF, now part of this category).

Defenses:

  • Deny by default and check authorization on the server for every request, on the resource level — not just "is logged in".
  • Never trust IDs from the client. Look up records scoped to the current user or tenant.
  • For SSRF, validate and allow-list destination hosts for any server-side fetch, and block access to internal and metadata IP ranges.
// Next.js route handler: scope the query to the authenticated user
export async function GET(_req: Request, { params }: { params: Promise<{ id: string }> }) {
  const { id } = await params
  const session = await auth()
  if (!session) return new Response("Unauthorized", { status: 401 })
  const order = await db.order.findFirst({ where: { id, customerId: session.user.id } })
  if (!order) return new Response("Not found", { status: 404 })   // don't reveal existence
  return Response.json(order)
}

Server Actions in Next.js are public HTTP endpoints too; check authorization inside each one, as you would in an API route.

A02: Security Misconfiguration

Default credentials, verbose error pages, open cloud storage buckets, permissive CORS, missing security headers and debug modes in production. Its rise to #2 reflects how much of modern security lives in configuration.

Defenses: infrastructure as code with reviewed defaults, security headers (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options), separate configurations per environment, and automated configuration scanning in CI. Our pipeline template is in CI/CD without pain.

A03: Software Supply Chain Failures

The new category covers everything between your code and production: dependencies, build systems, CI pipelines, container images and package registries. The March 2025 compromise of the popular tj-actions/changed-files GitHub Action, which exposed secrets from thousands of repositories, is a textbook example (CISA, 2025).

Defenses:

  • Lockfiles, dependency review on pull requests and automated updates with tests.
  • Pin CI actions and base images to digests; minimize permissions of CI tokens.
  • Generate SBOMs, sign artifacts and verify signatures before deployment.

We cover SBOMs, signing and SLSA in detail in Container and supply chain security.

A04: Cryptographic Failures

Sensitive data transmitted or stored without proper protection: plain HTTP, weak hashing of passwords, home-made encryption, keys in source code. Use TLS everywhere, a modern password hashing function such as Argon2id or bcrypt, your platform's vetted crypto libraries, and a secrets manager instead of environment files in Git.

A05: Injection

SQL, NoSQL, OS command, LDAP and template injection, plus cross-site scripting. ORMs and parameterized queries solve most SQL injection; output encoding and a strict Content Security Policy limit XSS. Be careful with raw query helpers and with dangerouslySetInnerHTML in React: sanitize HTML from users or from Markdown before rendering it.

For applications with LLM features, output from the model is untrusted input too. Treat it like user input before rendering or executing it, as we explain in AI agent security.

A06: Insecure Design

Flaws that no amount of correct coding fixes: password reset flows that leak whether an account exists, business logic that allows negative quantities in a cart, missing rate limits on expensive operations. Threat modeling during design, abuse cases next to user stories, and secure design patterns are the defense.

A07: Authentication Failures

Credential stuffing, weak password policies, broken session handling, missing multi-factor authentication. Use a proven identity provider or framework, support passkeys or MFA, rate-limit login attempts, rotate session identifiers after login and invalidate them on logout.

A08: Software or Data Integrity Failures

Trusting code or data without verifying integrity: auto-updates without signatures, deserializing untrusted data, CI pipelines that accept unreviewed changes. Verify signatures, avoid unsafe deserialization (classic in Java ecosystems), and protect build pipelines with branch protection and required reviews.

A09: Security Logging and Alerting Failures

Breaches are often discovered months later because nobody was alerted. Log authentication events, access control failures and high-value transactions with enough context; send them to a central system; and — the new emphasis — make sure alerts reach a person who acts on them.

A10: Mishandling of Exceptional Conditions

The second new category covers what happens when things go wrong: error handling that fails open, unhandled exceptions that leave transactions half-applied, stack traces leaking internals, or race conditions under load.

// Fail closed: an error in the permission check must deny, not allow
boolean canAccess;
try {
    canAccess = permissionService.check(user, resource);
} catch (Exception e) {
    log.error("Permission check failed for user={} resource={}", user.id(), resource.id(), e);
    canAccess = false;
}
if (!canAccess) throw new AccessDeniedException("Forbidden");

Defenses: fail closed, wrap multi-step changes in transactions, return generic error messages to clients while logging details internally, and test failure paths — timeouts, partial outages, malformed input — not just the happy path.

Turning the list into practice

  1. Map your threats to the ten categories for each application and prioritize by exposure.
  2. Automate what can be automated: dependency scanning, SAST, secret scanning, configuration checks and DAST in CI.
  3. Review what can't: access control and design flaws need human review and tests.
  4. Train developers on the categories most relevant to your stack.
  5. Use the OWASP ASVS when you need a detailed, testable checklist rather than an awareness document (OWASP ASVS).

A security checklist for code review

Add these questions to your pull request template; they catch a large share of Top 10 issues before they ship:

  • Does every new endpoint or Server Action check authorization on the resource, not just authentication?
  • Is any user input used in a query, command, template or HTML without parameterization or encoding?
  • Do error handlers fail closed and avoid returning internal details to the client?
  • Are new dependencies necessary, maintained and pinned?
  • Are secrets kept out of code, logs and client bundles?
  • Are security-relevant events logged with enough context?

FAQ

Is the OWASP Top 10 a compliance standard? No. It is an awareness document. For verifiable requirements, use the OWASP Application Security Verification Standard (ASVS).

Why did injection drop to #5? Frameworks, ORMs and secure defaults made it less prevalent in tested applications. It still causes severe breaches when it occurs.

Does the list cover LLM-specific risks? No. OWASP maintains a separate Top 10 for LLM applications, which covers prompt injection and related risks.

How often is the list updated? Roughly every three to four years; the previous edition was 2021.

Where should a small team start? With A01 and A02: authorization checks on every resource and safe configuration defaults. They cover the most common and most damaging issues.

Sources

  1. OWASP. OWASP Top 10:2025 and Introduction.
  2. OWASP. Application Security Verification Standard (ASVS).
  3. CISA (2025). Supply chain compromise of tj-actions/changed-files (CVE-2025-30066).
  4. OWASP GenAI Security Project. OWASP Top 10 for LLM Applications.