OWASP Top 10 2025 Explained: The 10 Biggest Web Application Security Risks

The OWASP Top 10 is the most widely referenced list of web application security risks. Security teams map findings to it, procurement questionnaires ask about it, and developers are expected to know it. The OWASP Top 10 2025 is the first update since 2021. It adds two new categories, merges others, and reorders the list based on data from over 2.8 million applications.

This guide covers all ten categories in the official order, using OWASP's exact names. For each one you get what it means, what it looks like in a real application, and what to do about it. Where code helps, there is code.

Key takeaways

• Broken Access Control is still number one, and Server-Side Request Forgery (SSRF) is now part of it.
• Two categories are new: Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10).
• Security Misconfiguration jumped from fifth to second place.
• The Top 10 is an awareness document, not a testing standard. To verify an application, use the OWASP ASVS and a structured test such as a web application penetration test.

Table of contents

• What the OWASP Top 10 is (and what it isn't)
• What changed from 2021 to 2025
• The OWASP Top 10 2025 risks
  • A01:2025 – Broken Access Control
  • A02:2025 – Security Misconfiguration
  • A03:2025 – Software Supply Chain Failures
  • A04:2025 – Cryptographic Failures
  • A05:2025 – Injection
  • A06:2025 – Insecure Design
  • A07:2025 – Authentication Failures
  • A08:2025 – Software or Data Integrity Failures
  • A09:2025 – Security Logging and Alerting Failures
  • A10:2025 – Mishandling of Exceptional Conditions
• How to use the Top 10 in your development process
• Common misconceptions
• OWASP Top 10 2025 checklist
• Frequently asked questions
• Conclusion
• References

What the OWASP Top 10 is (and what it isn't)

The OWASP Top 10 is published by the Open Worldwide Application Security Project (OWASP) Foundation. It is a consensus document about the most critical security risks to web applications. Each entry is a category of weaknesses rather than a single bug, and each category groups related entries from MITRE's Common Weakness Enumeration (CWE).

According to OWASP's introduction to the 2025 edition:

• Contributors supplied data on over 2.8 million applications, covering 589 CWEs (up from almost 400 in 2021).
• Eight categories were selected from that data. Two were promoted by a community survey of practitioners, to capture risks that testing data is slow to reflect.
• The ten categories together contain 248 CWEs.

OWASP introduced the 2025 list as a release candidate in November 2025, gathered public feedback, and then published the final edition.

What it isn't:

• Not a compliance standard. It does not define pass/fail requirements. That is the job of the OWASP Application Security Verification Standard (ASVS).
• Not a testing methodology. For that, use the OWASP Web Security Testing Guide (WSTG).
• Not a complete list. An application can be free of all ten categories and still have serious business-logic flaws.

What changed from 2021 to 2025

Three shifts matter most in practice:

1. The supply chain is now a first-class risk. "Use up-to-date libraries" has grown into a category about the whole path from dependency to build pipeline to deployment.
2. Errors and edge cases have their own category. How an application behaves when something goes wrong, such as a timeout, a missing parameter or a half-finished transaction, is now treated as a security property.
3. Alerting, not just logging. Collecting logs that nobody looks at doesn't count. The renamed A09 emphasizes detection and response.

The OWASP Top 10 2025 risks

A01:2025 – Broken Access Control

What it is. Access control decides who can do what to which data. It fails when users can act outside their intended permissions: reading another customer's records, calling admin functions, or editing data they should only view. OWASP maps 40 CWEs to this category, including Cross-Site Request Forgery (CWE-352) and, new in 2025, Server-Side Request Forgery (CWE-918).

How it shows up. The most common form is an insecure direct object reference (IDOR). The application takes an identifier from the request and never checks that the caller owns the record.

// Vulnerable: any logged-in user can read any invoice by changing the ID
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

// Fixed: the lookup is scoped to the caller's account
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findFirst({
    where: { id: req.params.id, accountId: req.user.accountId },
  });
  if (!invoice) return res.status(404).end(); // don't reveal that it exists
  res.json(invoice);
});

The fix doesn't hide the ID or make it harder to guess. It makes ownership part of the query, so a request for someone else's record returns nothing.

Other patterns:

• Admin pages that are only hidden in the UI ("force browsing").
• APIs that check permissions on GET but forget PUT and DELETE.
• Tampered JWT claims or cookies.
• Overly permissive CORS.
• SSRF: the server fetches a URL the attacker supplies and reaches internal services.

Prevention:

• Deny by default.
• Implement authorization once, in a shared layer, and reuse it.
• Enforce record ownership in the data layer.
• Write automated tests that assert another user is refused.
• For SSRF, validate outbound destinations against an allowlist and block internal address ranges at the network level as well.

In APIs this flaw is so common it has its own name, Broken Object Level Authorization. It is the subject of our upcoming deep dive on BOLA.

A02:2025 – Security Misconfiguration

What it is. The system is "set up incorrectly from a security perspective." Typical causes: default credentials, sample apps left on production servers, directory listing, verbose stack traces, unnecessary features enabled, or cloud storage shared publicly by default. XML External Entity (XXE) issues (CWE-611) are mapped here too, because they usually come from an unsafe parser default.

Why it climbed to #2. Modern applications are mostly configuration: frameworks, containers, cloud IAM, CDN rules, security headers. Every layer has its own defaults, and each one can be wrong.

Prevention:

• Use a repeatable, automated hardening process, so development, staging and production are configured the same way but with different credentials.
• Start from a minimal platform. Remove sample code, unused features and admin consoles.
• Send security headers (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options).
• Route all errors through a central handler that returns a generic message to users.
• Prefer short-lived credentials and identity federation over secrets embedded in configuration files.
• Re-check configuration continuously. A setting that was correct at launch can drift.

A03:2025 – Software Supply Chain Failures

What it is. OWASP defines these as "breakdowns or other compromises in the process of building, distributing, or updating software." This covers vulnerable dependencies, malicious packages, compromised build tools and weak CI/CD controls. In the contributed data this category had the highest average incidence rate. It was also one of the two categories the community survey placed on the list.

Real incidents cited by OWASP include the SolarWinds compromise, the Shai-Hulud self-propagating npm worm (2025), and component flaws such as Log4Shell (CVE-2021-44228).

Warning signs:

• No inventory of direct and transitive dependencies.
• Patches applied in monthly or quarterly batches.
• No subscription to security advisories.
• A CI/CD pipeline that is less protected than the production systems it deploys to.

Prevention:

• Generate and maintain a Software Bill of Materials (SBOM) for every application.
• Monitor dependencies continuously, with tools such as OWASP Dependency-Track or Dependency-Check against the CVE, NVD and OSV databases.
• Remove unused dependencies.
• Pull packages only from trusted registries, and prefer signed packages.
• Protect the pipeline: MFA, least privilege, signed builds, and build provenance. The SLSA framework is a useful model.
• Roll out changes gradually (canary or staged deployments), so a compromised update has limited reach.

A04:2025 – Cryptographic Failures

What it is. Sensitive data is exposed because cryptography is missing, weak or misused. Examples: passwords stored with fast hashes, data sent over plain HTTP, hard-coded keys, outdated algorithms, or predictable random values used for tokens.

# Store passwords with a slow, salted, memory-hard hash.
# Never use a fast general-purpose hash such as SHA-256 for passwords.
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

ph = PasswordHasher()
stored_hash = ph.hash(password)        # at registration

try:
    ph.verify(stored_hash, attempt)    # at login
except VerifyMismatchError:
    deny_login()

Prevention:

• Classify data, so you know what needs protecting.
• Encrypt in transit with TLS everywhere, and add HSTS.
• Encrypt sensitive data at rest, with keys held in a managed key service rather than in code.
• Hash passwords with Argon2id, scrypt or bcrypt, as recommended by the OWASP Password Storage Cheat Sheet.
• Generate tokens with a cryptographically secure random source.

A05:2025 – Injection

What it is. Untrusted input is sent to an interpreter, such as SQL, a shell, LDAP, a template engine or the browser's DOM, in a way that changes the command's meaning. Cross-site scripting (XSS) belongs to this category.

# Vulnerable: the input becomes part of the SQL statement
cur.execute(f"SELECT id, name FROM users WHERE email = '{email}'")

# Safe: the driver sends the value separately from the query
cur.execute("SELECT id, name FROM users WHERE email = %s", (email,))

With the parameterized version, an input such as ' OR '1'='1 is treated as a literal email address. It can't change the query's logic.

Prevention:

• Use parameterized queries or a safe ORM API.
• Avoid shell execution with user input. If unavoidable, pass arguments as an array, never as a concatenated string.
• Use context-aware output encoding for HTML, plus a Content Security Policy.
• Validate input against allowlists where the format is known.

See the OWASP Query Parameterization Cheat Sheet and the XSS Prevention Cheat Sheet.

A06:2025 – Insecure Design

What it is. Flaws in the design itself, not in its implementation. Perfect code can't fix a design that never considered abuse. Examples:

• A password-reset flow that relies on guessable security questions.
• A checkout with no limit on how many discount codes can be applied.
• A booking system that lets one account reserve every seat without paying.

Prevention:

• Threat-model new features before building them. Ask "how would someone misuse this?" alongside "how will someone use this?"
• Write abuse cases next to user stories.
• Use secure design patterns, such as tenant isolation and rate limits on business flows.
• Have security review the architecture, not only the code.

A07:2025 – Authentication Failures

What it is. The system can be tricked into treating an attacker as a legitimate user. OWASP maps 36 CWEs here. Common causes:

• No defense against credential stuffing or password spraying.
• Weak or known-breached passwords accepted.
• Missing MFA.
• Session IDs exposed in URLs.
• Sessions that survive logout.

Prevention:

• Enforce multi-factor authentication where possible.
• Throttle failed logins without creating a denial-of-service lever, and alert on attack patterns.
• Check new passwords against lists of breached credentials. Follow NIST SP 800-63B rather than forced rotation and complexity rules.
• Issue a fresh, high-entropy session ID after login, and invalidate it at logout and on idle or absolute timeouts.
• Use a proven identity platform instead of building your own authentication.

A08:2025 – Software or Data Integrity Failures

What it is. The application trusts code or data without verifying its integrity. Examples:

• Loading scripts or plugins from untrusted sources.
• Auto-updates without signature checks.
• Pipelines that use unverified artifacts.
• Deserializing objects an attacker can modify.

OWASP describes this as integrity "at a lower level" than A03. Interestingly, mass assignment (CWE-915, Improperly Controlled Modification of Dynamically-Determined Object Attributes) is mapped here.

Example. A front end stores serialized Java objects in client state. An attacker recognizes the Java serialization signature (rO0 in Base64), crafts a malicious object, and achieves remote code execution when the server deserializes it.

Prevention:

• Verify signatures on code, updates and artifacts.
• Never deserialize untrusted data with native serializers. Use simple data formats such as JSON with strict schemas.
• Review changes before they enter the pipeline.
• Bind only allowlisted fields from request bodies to your models.

A09:2025 – Security Logging and Alerting Failures

What it is. Attacks go unnoticed because security-relevant events are not logged, logs aren't monitored, or nobody gets alerted. The rename from "Monitoring" to "Alerting" is deliberate: detection only has value if someone acts on it.

Log at least:

• Authentication successes and failures.
• Access-control denials.
• Input-validation failures on sensitive endpoints.
• Administrative actions.
• Changes to permissions.

Prevention:

• Use a consistent, machine-readable log format, and send logs to a central system the application cannot overwrite.
• Define alerts for patterns such as repeated access denials.
• Encode log output to prevent log injection.
• Never log secrets, tokens or full payment data.
• Rehearse your incident response.

See the OWASP Logging Cheat Sheet.

A10:2025 – Mishandling of Exceptional Conditions

What it is. New in 2025, with 24 mapped CWEs. It covers software that fails to prevent, detect or respond correctly to unusual situations. Causes include:

• Unhandled exceptions and unchecked return values.
• Missing-parameter handling.
• Error messages that leak internals.
• "Failing open" (CWE-636): treating an error as permission to continue.

// Fails OPEN: if the policy service is down, everyone gets access
async function canRead(user, doc) {
  try {
    return await policy.check(user.id, doc.id, "read");
  } catch {
    return true;
  }
}

// Fails CLOSED: errors are logged and access is denied
async function canRead(user, doc) {
  try {
    return await policy.check(user.id, doc.id, "read");
  } catch (err) {
    logger.error({ err, userId: user.id }, "policy check failed");
    return false;
  }
}

OWASP's scenarios include:

• Resource exhaustion, when exceptions skip cleanup.
• Database errors that reveal enough detail to help an SQL injection attack.
• Interrupted multi-step money transfers that leave the system half-updated.

Prevention:

• Handle errors where they occur.
• Roll back incomplete transactions entirely.
• Keep a global exception handler as a safety net.
• Return generic error messages to users. RFC 9457 problem details work well for APIs.
• Rate-limit and set resource quotas.
• Alert on repeated errors.

How to use the Top 10 in your development process

The Top 10 is most valuable as a shared vocabulary across the lifecycle:

1. Design. During threat modeling, walk through A01, A06 and A10 for each new feature. Ask who should be able to do this, how it could be abused, and what happens when it fails.
2. Build. Map secure-coding standards to each category, such as parameterized queries for A05 and the central authorization layer for A01. Add checks to code review.
3. Dependencies. Automate SBOM generation and dependency alerts for A03, and pin and verify artifacts for A08.
4. Test. Run automated scans in CI. Most A01 and A06 issues need human testing, though, because scanners can't tell whether user B should see user A's invoice. Use the OWASP WSTG for coverage.
5. Verify. Before major releases, commission an independent assessment. A vulnerability assessment gives you breadth, and a penetration test gives you depth.
6. Operate. Set alerts for A09 and check that they fire. A test that triggers an access-control denial should produce an alert someone sees.

Common misconceptions

• "Our scanner covers the OWASP Top 10." Scanners find many injection and misconfiguration issues. They are weak at authorization and design flaws, which are the top of the list and the most damaging in practice.
• "Compliant with OWASP Top 10" means secure. There is no certification for the Top 10. If a report claims "OWASP compliance", ask which ASVS level was verified and how.
• "Random IDs fix IDOR." Unpredictable identifiers make enumeration harder, but they are not authorization. IDs leak through URLs, logs and shared links.
• "Logging equals monitoring." A09 explicitly requires alerting. Logs that nobody reviews won't stop an attack in progress.
• "Supply chain risk means updating npm packages." A03 also covers your build system, CI/CD credentials and artifact registries.

OWASP Top 10 2025 checklist

Use this as a starting point for a design or pre-release review:

• Authorization is enforced server-side, deny-by-default, with ownership checks in the data layer (A01).
• Outbound requests built from user-supplied URLs are restricted to an allowlist (A01, SSRF).
• Production has no default credentials, debug modes, sample apps or directory listings, and security headers are set (A02).
• An SBOM exists, and dependency alerts are monitored and patched promptly (A03).
• CI/CD uses MFA, least privilege and signed artifacts (A03, A08).
• TLS everywhere, HSTS enabled, passwords hashed with Argon2id, scrypt or bcrypt (A04).
• All database queries are parameterized, and HTML output is context-encoded (A05).
• New features are threat-modeled, with abuse cases and business-flow limits (A06).
• MFA is available, breached passwords are rejected, and sessions rotate on login and expire (A07).
• No native deserialization of untrusted input, and request bodies bind only allowlisted fields (A08).
• Security events are logged centrally, and alerts are defined and tested (A09).
• Errors fail closed, transactions roll back fully, and users see generic error messages (A10).

Frequently asked questions

What is the OWASP Top 10 2025?

The OWASP Top 10 2025 is the current edition of OWASP's awareness list of the most critical web application security risks. It replaces the 2021 edition and was built from data on more than 2.8 million applications, plus a community survey.

What is new in the OWASP Top 10 2025?

Two categories are new: A03 Software Supply Chain Failures and A10 Mishandling of Exceptional Conditions. SSRF was merged into A01 Broken Access Control. Security Misconfiguration moved up to A02, and two categories were renamed: Authentication Failures and Security Logging and Alerting Failures.

Is XSS still in the OWASP Top 10?

Yes. Cross-site scripting is part of A05:2025 Injection. It no longer has its own category, but it remains one of the most common web vulnerabilities.

Where is SSRF in the 2025 list?

Server-Side Request Forgery (CWE-918) was a standalone category in 2021 (A10:2021). In 2025 it is part of A01 Broken Access Control.

Can an automated scanner test for the whole OWASP Top 10?

No. Scanners help with injection, misconfiguration and known-vulnerable components. Access control, insecure design and business logic need manual testing by someone who understands what the application is supposed to allow.

How is the OWASP Top 10 different from the OWASP API Security Top 10?

They are separate projects. The API Security Top 10 (current edition 2023) focuses on API-specific risks such as Broken Object Level Authorization and Unrestricted Resource Consumption. If you build APIs, use both.

How often is the OWASP Top 10 updated?

Roughly every three to four years. The previous editions were 2017 and 2021.

Conclusion

The 2025 list is a reminder that application security is not only about input validation. The biggest risks are about trust: who is allowed to do what (A01), what your configuration actually permits (A02), which code you are really running (A03, A08), and what happens when things go wrong (A10). Treat the list as a vocabulary for design reviews, code reviews and testing, not as a box to tick.

If you want to know how your application measures up, Cyber Secret Society's web application penetration testing maps every finding to the OWASP Top 10 and gives your developers practical fixes. For a broader first pass, start with a vulnerability assessment. Developers who want hands-on practice can explore our CTF challenges and security glossary.

References

• OWASP Top 10:2025 – official list and introduction and changes
• OWASP category pages: A01, A02, A03, A04, A05, A06, A07, A08, A09, A10
• OWASP Application Security Verification Standard (ASVS)
• OWASP Web Security Testing Guide (WSTG)
• OWASP Cheat Sheets: Password Storage, Query Parameterization, XSS Prevention, Logging, SSRF Prevention
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management
• MITRE CWE-918: Server-Side Request Forgery
• SLSA – Supply-chain Levels for Software Artifacts
• RFC 9457 – Problem Details for HTTP APIs
• PortSwigger Web Security Academy – Access control