OWASP Top 10 (2025): What We Know, What's Likely, and What Hasn't Changed

Why the list changes (and why most of it doesn't)

OWASP Top 10 is updated every three to four years based on industry data calls and survey input. The categories you see in any given edition reflect both how often a class of bug shows up across reported data and how the community is writing about emerging issues. Because the underlying patterns of insecure software change slowly, most categories carry over from one edition to the next under similar names.

What does change between editions tends to be:

• Naming and grouping. Categories merge, split, or get renamed for clarity.
• Ordering. Movement up and down the list reflects changing prevalence in the dataset.
• New categories. Issues that were sub-items of other categories get promoted as the community writes more about them.
• Coverage of newer technology. Cloud-native patterns, supply chain, identity-as-a-service.

The canonical 2021 list (still the one that matters)

This is the list your customers and auditors are mapping to right now. Every category here continues to dominate real-engagement findings:

Rank	Category	Why it sits here
A01	Broken Access Control	Most prevalent and highest-impact category in real engagements. Includes IDORs, BOLA/BFLA, and tenant boundary flaws.
A02	Cryptographic Failures	Renamed from "Sensitive Data Exposure". Covers weak ciphers, missing TLS, weak key handling, and protocol-level mistakes.
A03	Injection	SQL, NoSQL, LDAP, OS command injection, plus cross-site scripting (folded in from a separate 2017 category).
A04	Insecure Design	New in 2021. Architectural and threat-modeling failures that no amount of patching individual bugs will fix.
A05	Security Misconfiguration	Default credentials, verbose errors, missing security headers, outdated frameworks, debug features in production.
A06	Vulnerable and Outdated Components	Dependency hygiene, missing patches, end-of-life software still in production.
A07	Identification and Authentication Failures	Renamed from "Broken Authentication". Brute-force resistance, session handling, MFA bypass paths, recovery flow safety.
A08	Software and Data Integrity Failures	New in 2021. CI/CD trust, dependency confusion, deserialization, auto-updates without integrity checks.
A09	Security Logging and Monitoring Failures	Missing audit trails, missing alerting on critical events, logs that an attacker can erase.
A10	Server-Side Request Forgery (SSRF)	New as a top-level category in 2021. Cloud metadata service abuse made this a much bigger deal than it used to be.

What the 2025 process is shaping up to address

OWASP runs a public process for each revision: data calls, survey input, and open discussion in the OWASP repositories. From what is visible in those public discussions, four themes are likely to influence the 2025 list. We are not announcing categories — those are determined by OWASP, not us — only describing emphasis areas surfaced in the public process.

Supply chain integrity expanding

The 2021 A08 (Software and Data Integrity Failures) was a meaningful addition that covered CI/CD and dependency-confusion patterns. The community discussion since 2021 — driven by SolarWinds-class incidents and the rise of dependency-poisoning research — suggests this area gets more depth in 2025. Expect explicit treatment of build pipeline security, signed artifacts, and producer-side compromise.

Identity and access depth

Broken Access Control sits at A01 and is unlikely to move. What may evolve is how the category is described — explicit treatment of multi-tenant SaaS boundaries, identity federation paths (SSO downgrade, SAML assertion handling, SCIM provisioning), and machine-to-machine identity (workload identities, OIDC for workloads). The underlying issues are not new; the 2021 category just covers them implicitly.

SSRF and metadata-service abuse

SSRF entered the top 10 in 2021 partly because of cloud-metadata-service exploitation patterns. The cloud surface has only grown since. Expect either expansion within an SSRF-equivalent category or sub-treatments for metadata abuse and outbound-request safety on serverless.

API-specific patterns within the main list

OWASP API Security Top 10 is its own list (separate from the main Top 10) and has its own active community. The main list traditionally references API issues at a high level. There is community discussion of bringing more API-specific framing into the main 2025 list — particularly around BFLA (function-level access) and rate-limiting patterns that web frontends and APIs share.

What doesn't change regardless of edition

If you are scoping a pentest or hardening a codebase, the categories below have dominated real-engagement findings for over a decade and are unlikely to leave the conversation:

• Authorization is the durable problem. Whatever it is called and wherever it is ranked, broken access control is the most common high-impact finding in modern web and API engagements.
• Identity and authentication edge cases. Account recovery, SSO federation, machine identity. The technology shifts; the category does not.
• Insecure design. No amount of patching individual bugs replaces a threat model that thinks about misuse.
• Configuration drift. Default credentials, public storage, exposed admin endpoints. Continuous coverage matters.
• Logging and detection. Logs that don't exist or that an attacker can erase undermine every other control.

How to test against the list now

For the next twelve months, the right move is straightforward: scope and report against the 2021 list because that is what auditors and customer questionnaires reference. Internally, anticipate the 2025 emphasis areas — supply chain, identity, SSRF expansion — by adding depth in those areas without retitling the report.

Three questions to ask in any web application or API engagement, regardless of which edition is current:

• Did the engagement test broken access control across every documented role and tenant?
• Did the engagement examine the full identity surface — including SSO downgrade, account recovery, and machine identity?
• Did the engagement evaluate the build and supply-chain surface, or only the running application?