AWASP Top Ten — Actual Web Application Security Project

#	Vulnerability	OWASP Equivalent
Loading…

Editorial note — data gap

A Note on Custom Web Applications

Most of the AWASP Top Ten describes vulnerabilities in vendor software that happens to be web-accessible — React Server Components, SharePoint, SAP NetWeaver, Apache Tomcat. The breach data we draw on is structurally poor at telling us what gets exploited in bespoke, custom-built web applications, because SEC filings and breach disclosures almost never specify a vulnerability class. They say “unauthorized access” and leave it there. What follows is what we can reasonably infer from the data we do have — presented in ranked order, with the honest caveat that inference is not evidence.

1

Credential stuffing against login endpoints

The most likely attack against any custom web application is not a code-level vulnerability at all — it’s an attacker replaying stolen username and password pairs bought from an access broker or extracted from infostealer logs. Your login page is the most attacked surface you own, and no amount of secure coding prevents it if your users reuse passwords from other breached services.

Basis: 88% of basic web application attack breaches in the 2025 Verizon DBIR involved stolen credentials. This is the one inference we can make with high confidence.
2

Broken access control and IDOR in APIs

The most likely code-level vulnerability to be actively exploited in a custom application. Changing a numeric ID in a request parameter requires no tooling, no expertise, and no CVE — just curiosity. It yields immediate access to other users’ data and is invisible to WAFs and SAST scanners. Custom apps built quickly around REST or GraphQL APIs are particularly prone, because authorisation checks are easy to forget on individual endpoints and there is no framework safety net.

Basis: BOLA/IDOR is the dominant finding class in API-focused bug bounty programmes. Custom app breach disclosures rarely name it, but the technical pattern is too common and too easy to exploit for it not to be occurring.
3

Business logic flaws

Price manipulation, coupon or voucher abuse, workflow bypass, and race conditions in payment or account flows are almost certainly underreported in public breach data. These flaws are unique to each application, don’t map to CVEs, can’t be found by scanners, and are frequently monetised quietly — by fraud rings who have no incentive to advertise their method. The absence of data here is not the absence of exploitation.

Basis: Inferred from fraud intelligence and bug bounty disclosures. Hard to quantify by definition — treat the data gap itself as signal.
4

SQL injection and XSS in custom code

These are genuinely getting rarer in applications built on modern frameworks. React, Django, Rails, and their ORMs provide safe defaults that prevent the majority of injection and reflected XSS cases without developers thinking about it. They persist in legacy codebases, internal tools, and anywhere a developer reaches past the framework to write a raw query or construct an HTML string by hand — but they are no longer the dominant risk they were a decade ago in custom application code specifically.

Basis: SAST/DAST scan data still finds these at high rates, which inflates their apparent prevalence. Exploited incidence in modern custom apps is likely lower than scan findings suggest.
5

Misconfigured cloud storage and exposed API endpoints

Probably causing more custom-application breaches than injection flaws, but almost never categorised as a specific vulnerability class. A publicly readable S3 bucket, a debug endpoint left in production, an internal API reachable from the internet, an unauthenticated admin route — these are the infrastructure and deployment mistakes that leak data at scale. They surface as “unauthorized access” in disclosures and are structurally invisible in any list derived from CVE or pentest data.

Basis: Cloud misconfiguration features heavily in IR investigations but almost never in public breach attributions. The classification gap is the problem, not a lack of incidents.

Your biggest risk is almost certainly weak authentication and broken access control in your APIs — not injection flaws.

Methodology

Transparent about our sources, our reasoning, and where the data runs out.

The OWASP Top 10 is built from testing data — what security scanners and pentesters find when they examine applications. That’s useful, but it tells you what’s discoverable, not what’s actually being exploited. We wanted to know what attackers are actually doing, so we went looking for exploitation data instead.

Sources we used

CISA Known Exploited Vulnerabilities Catalog

245 vulnerabilities added in 2025, filtered to web application vulnerabilities only

The US government’s definitive list of vulnerabilities confirmed to be actively exploited in the wild. We categorised additions by CWE type to identify which vulnerability classes appear most often.

Verizon Data Breach Investigations Report (DBIR) 2025

22,052 incidents, 12,195 confirmed breaches, 139 countries

The largest annual breach study. Tells us how attackers get in and what types of attacks hit web applications specifically — not what testers find, but what’s actually happening.

Mandiant M-Trends 2025

Incident response data from one of the largest breach investigation firms

Initial access vectors from real engagements, not simulated tests. Mandiant sees the aftermath of actual breaches, which gives different signal to penetration testing data.

Recorded Future 2025 Exploitation Reports

161 exploited CVEs tracked in H1 2025 with attribution data

Shows who is exploiting what — state-sponsored groups, ransomware operators, financially motivated attackers — and in what volumes. Attribution data helps distinguish mass exploitation from targeted campaigns.

SEC 8-K Cybersecurity Filings

Material cybersecurity incident disclosures mandatory for US public companies since December 2023

A ground-truth view of what’s actually hurting organisations badly enough to tell investors about. Biased toward large enterprises, but one of the few sources with real-world impact data.

Individual Breach Disclosures & Advisories

Specific high-profile incidents reviewed individually (Conduent, Prosper Marketplace, French retail chain compromises, and others)

Aggregated datasets miss the detail. Reading individual breach disclosures tells us the specific vulnerability class, affected component, and attacker method in ways that statistics don’t.

Scope

What we deliberately excluded

We filtered out anything that isn’t a web application vulnerability. CISA KEV is full of Use After Free bugs, buffer overflows, and kernel privilege escalations — those are real and serious, but they’re not web app security.

We kept the focus on vulnerabilities in things you access over HTTPS: login pages, APIs, web management interfaces, and web application frameworks.

vs OWASP

What makes this different from OWASP

OWASP’s data contributors are security testing vendors (Veracode, Contrast Security, HackerOne). Zero breach investigation firms — Mandiant, CrowdStrike, Palo Alto Unit 42 — contribute data to the OWASP Top 10.

OWASP uses incidence rate (percentage of apps with the vulnerability) rather than exploitation frequency. Two of their ten categories are chosen by community survey to compensate for things testing tools can’t find. Their own documentation says results are “largely limited to what the industry can test for in an automated fashion.”

None of that makes OWASP wrong or useless. It just means it answers a different question to ours.

Honest limitations

▸ Breach data is structurally biased toward what gets reported. Many breaches never become public.
▸ SEC filings are deliberately vague — companies say “unauthorized access” not “IDOR in our claims API” because their lawyers tell them to.
▸ CISA KEV skews toward vulnerabilities in vendor products (the ones that get CVEs), not custom application flaws.
▸ We can’t precisely rank what code-level vulnerabilities get exploited in bespoke web applications because nobody publishes that data in enough detail. We’ve been honest about this gap in the list itself.
▸ This is a snapshot based on 2025 data. The threat landscape shifts. We plan to revisit this annually rather than treating it as a static ranking.

The AWASP Top Ten

A different kind of top ten

○ Other frameworks

✓ AWASP

AWASP Top Ten — 2025

A Note on Custom Web Applications

Notable absences from OWASP

Methodology

Primary data sources

About this project