What are the most common web application attack vectors in 2026?

Six of them account for most real damage. Broken access control including IDOR and BOLA, authentication and session attacks, exploitation of known vulnerabilities in public facing applications, API layer and business logic abuse, software supply chain compromise, and injection including server side request forgery. The Verizon 2026 DBIR found vulnerability exploitation is now the top initial access vector at 31 percent, up from 20 percent.

What changed in the OWASP Top 10 2025 compared to 2021?

Broken Access Control stayed at number one and absorbed server side request forgery, which was a standalone category in 2021. Security Misconfiguration climbed from fifth to second. Two categories are new: Software Supply Chain Failures at number three and Mishandling of Exceptional Conditions at number ten. Injection fell from third to fifth and Cryptographic Failures fell from second to fourth. Authentication Failures and Security Logging and Alerting Failures were renamed.

How often should web applications be security tested?

As often as they change. Frameworks set a floor rather than a target. PCI DSS requires penetration testing at least every 12 months and after any significant change, plus quarterly vulnerability scans. RBI requires vulnerability assessment at least half yearly and penetration testing at least annually. If you deploy weekly, a quarterly test leaves roughly a dozen releases untested, and the 2026 DBIR shows the median time to fully remediate a known exploited vulnerability has stretched to 43 days.

Why cannot automated scanners find broken access control vulnerabilities?

Because there is nothing malformed to detect. A broken access control request is a perfectly valid request sent by the wrong person. The scanner has no way to know that account 41007 should not be able to read account 88213 unless it understands your business rules. This is why Akamai found behaviour based attacks rose from 30 percent of API attacks in 2024 to 61 percent in 2025. There is no payload to signature, only a legitimate request in an illegitimate sequence.

What percentage of breaches start with exploiting a web application vulnerability?

The Verizon 2026 DBIR puts vulnerability exploitation at 31 percent of all breaches as the initial access vector, up from 20 percent the prior year, which is a 55 percent year on year rise and the first time in the report's 19 year history that it has passed stolen credentials. IBM X-Force separately found exploitation of public facing applications became the most common initial access vector, up 44 percent.

6 Attack Vectors Every Web App Should Be Tested Against

For nineteen years the Verizon DBIR said the same thing. Attackers log in. In 2026 that changed.

The 2026 report found that 31 percent of breaches now start with exploiting a vulnerability, up from 20 percent. That is a 55 percent rise in one year, and the first time in the report's history that exploitation has beaten stolen credentials as the top way in. IBM X-Force found the same shift from a different dataset: exploitation of public-facing applications became the most common initial access vector, up 44 percent.

If your web app is now the most likely way in, what exactly should you be testing it against? Six things. Here they are.

Start from the current OWASP list, not the old one

OWASP Top 10:2025 is the current edition. It was announced as a release candidate in November 2025 and finalised in January 2026, and it changed meaningfully. Broken Access Control stayed at number one and absorbed SSRF. Security Misconfiguration climbed from fifth to second. Two categories are new: Software Supply Chain Failures at A03 and Mishandling of Exceptional Conditions at A10. Injection fell from third to fifth.

The most interesting entry is A03. Software Supply Chain Failures was ranked number one by exactly 50 percent of respondents in OWASP's community survey, yet it maps to only 11 CVEs. Practitioners know it is the biggest problem. The CVE feed cannot see it. That explains a lot about what your tooling is telling you.

31%

Of breaches start with vulnerability exploitation (Verizon 2026) — up from 20%

61%

Of API attacks are behaviour-based, up from 30% in 2024 (Akamai)

26%

Of known exploited vulnerabilities fully remediated (Verizon 2026) — down from 38%

The six vectors, and why scanners struggle with four of them

1. Broken access control, IDOR and BOLA. A perfectly valid request, sent by the wrong person. Change an account ID in a URL and read someone else's statement. Call an admin endpoint from a normal session. This has been number one on the OWASP list for years and it still is. OWASP records 3.74 percent average incidence, 20.15 percent maximum, across 1,839,701 occurrences. Scanners miss it because there is nothing malformed to detect. The request is legitimate. Only your business rules say who should be allowed to send it.

2. Authentication and session attacks. Credential stuffing, password spray, session fixation, tokens that outlive the session, resets that can be replayed. Cloudflare 2026: 94 percent of all login attempts come from bots, and 63 percent of logins involve credentials already compromised elsewhere. Scanners test one request at a time. Volume and behaviour tell the story.

3. Exploitation of known vulnerabilities in public-facing apps. The unglamorous one, and now the biggest. An unpatched framework, an exposed admin panel, a VPN appliance nobody owns. The DBIR found vulnerability exploitation is the number one initial access vector at 31 percent, up from 20 percent. Scanners find these. The failure is downstream: only 26 percent of known exploited vulnerabilities were fully remediated, and the median time to fix stretched to 43 days.

4. API abuse and business logic flaws. No payload, no exploit string. Just your own workflow, run in an order you did not plan for. Skip a step, replay a request, apply a discount twice. Akamai measured behaviour-based attacks rising from 30 percent of API attacks in 2024 to 61 percent in 2025. There is no payload to signature, only a legitimate request in an illegitimate sequence.

Akamai counted 258 API attacks per enterprise per day in 2025, against 121 in 2024. That is a 113 percent rise in a single year. API abuse is not a category to note and move on. It is the fastest-growing attack surface in most web applications.

5. Software supply chain and dependencies. You did not write the vulnerable code. You installed it. Sonatype 2026 counted 454,600 new malicious packages in 2025, over 99 percent on npm, and 1.23 million blocked cumulatively. OWASP added this as a new A03 category, and it maps to only 11 CVEs, because most supply chain compromise never reaches a CVE feed. DBIR 2026: third parties were involved in 48 percent of breaches, up 60 percent year on year.

6. Injection and server-side request forgery. SQLi, NoSQLi, LDAP injection, command injection, SSTI, and SSRF (now absorbed into A01 as part of access control). These are the best-covered of the six, which is exactly why they slipped down the list. HackerOne found 78 percent of valid automated hackbot submissions were XSS. The better your tooling covers injection, the more attackers moved somewhere else.

Scanners are excellent at things that look like vulnerabilities

Automated scanning is genuinely good. It is fast, cheap, repeatable and it catches a lot. The issue is not quality. It is shape. The vectors scanners handle well are the ones with a malformed request to detect. The vectors they struggle with are the ones where every individual request is perfectly valid.

The Top 10 is partly a map of what our tooling can see. Attackers do not work from that map.

Finding is not the failure. Fixing is.

Even where scanners work perfectly, the pipeline behind them leaks. The 2026 DBIR found that only 26 percent of CISA known exploited vulnerabilities were fully remediated, down from 38 percent, and the median time to full remediation grew to 43 days from 32. Between 60 and 70 percent of known exploited vulnerabilities were still open on day seven.

PCI DSS requirement 11.4.4 already says exploitable findings must be corrected and the test repeated to verify the correction. Most programmes treat that retest as an optional extra. Arxiis treats it as a default: every finding is re-tested automatically on the next run.

Cover the six, then keep covering them

The honest answer to testing frequency is: as often as the application changes. A team deploying weekly ships roughly a dozen changes between quarterly tests. Any one of them can reintroduce something the last test proved closed. Meanwhile Akamai counted 258 API attacks per enterprise per day in 2025, up from 121. The attacker's cadence is daily. The defender's cadence is quarterly at best.

Arxiis was built around this shape. An autonomous AI red team runs across 26 modules and 6 attack vectors against your live application, chains findings into real attack paths rather than listing them separately, maps results to MITRE ATT&CK, RBI and CERT-In, and re-earns a known-secure state every 24 hours.

Your pentest is a photo. The attacker is filming.

The vectors are not a secret. Every one of them is documented, categorised and measured by people who publish their data. What separates a covered application from an exposed one is not knowing the list. It is how recently someone actually tried them.

Close your security gaps — continuously.

Arxiis is an autonomous AI penetration-testing platform that runs a coordinated crew of specialist agents through a full engagement in hours, not weeks — continuously, not annually. Every finding is CVSS-scored, MITRE ATT&CK-tagged, and auto-mapped to RBI CSF, CERT-In and nine more frameworks. It runs entirely on your own infrastructure. Nothing leaves the perimeter.

6 Attack Vectors EveryWeb App Must Be Tested Against.