OWASP Top Ten 2026 – The Complete Guide

Updated August 27, 2026

The OWASP Top 10 in 2026 (officially the OWASP Top 10:2025), in order:

1. Broken Access Control
2. Security Misconfiguration
3. Software Supply Chain Failures
4. Cryptographic Failures
5. Injection
6. Insecure Design
7. Authentication Failures
8. Software or Data Integrity Failures
9. Security Logging & Alerting Failures
10. Mishandling of Exceptional Conditions

The OWASP Top 10 ranks the most critical security risks to web applications, built from contributed data covering hundreds of thousands of applications plus a broad industry survey. It isn’t a complete security framework, but it has become the de facto baseline for secure development: the list that shapes compliance checks, vendor questionnaires, and security training across the industry.

But the list alone isn’t the whole story: the scripts running in your users’ browsers (chat widgets, analytics tags, trackers) don’t map to one OWASP category. They map to four at once. More on that after the rundown.

Is There a New OWASP Top 10 for 2026?

No. OWASP updates the Top 10 roughly every four years: 2017, 2021, then the current version, which was published in November 2025 and finalized in January 2026. On that cadence, the next release is expected around 2028–2029, and OWASP has announced no date.

That makes the Top 10:2025 your working baseline for 2026: it’s the version auditors, procurement teams, and security questionnaires will reference this year. The 2025 update introduced two new categories (Software Supply Chain Failures and Mishandling of Exceptional Conditions), renamed two others, and retired Server-Side Request Forgery as a standalone category, folding it (CWE-918) into Broken Access Control. For the deep dive into every category and mitigation, see our complete OWASP Top 10:2025 guide.

What Changed From 2021 to 2025?

Three shifts tell the story. Supply chain risk entered at #3 (the highest debut on the list) because attackers increasingly compromise the components you trust rather than the code you wrote. Security Misconfiguration climbed to #2 because modern applications are assembled from dozens of configurable pieces, and OWASP’s data found some form of misconfiguration in 100% of applications tested. And the two renames (Authentication Failures, Logging & Alerting Failures) both narrow the focus to where incidents actually happen.

The OWASP Top 10 in 2026: All Ten Risks Explained

1. Broken Access Control (A01)

Broken access control means users can act outside their intended permissions: viewing other users’ data, escalating privileges, or modifying resources they shouldn’t touch. It holds #1 with 32,654 mapped CVEs, more than any other category, and now includes Server-Side Request Forgery (CWE-918). Mitigate with deny-by-default policies, role-based access control, and testing access rules as rigorously as features.

2. Security Misconfiguration (A02)

Security misconfiguration covers insecure defaults, overly permissive settings, unnecessary features, and unhardened components: anywhere the software is capable of being secure but isn’t set up to be. It jumped from #5 to #2 (OWASP found some form of misconfiguration in 100% of applications tested), and it extends well beyond servers: every third-party tag and script added to your pages is configuration someone has to govern. More on common misconfigurations, and on the client-side version of this risk, below.

3. Software Supply Chain Failures (A03)

Software supply chain failures are compromises of the components, build systems, and distribution channels your application depends on: the successor to 2021’s “Vulnerable and Outdated Components,” entering at #3. It carries the highest average incidence rate on the list (5.72%) yet maps to only 11 CVEs, because a poisoned dependency rarely gets a CVE before it does its damage. Think SolarWinds, Polyfill.io, and Shai-Hulud.

4. Cryptographic Failures (A04)

Cryptographic failures are weak, missing, or misused encryption (data transmitted in cleartext, deprecated algorithms, poor key management) that expose sensitive data. Down from #2, but no less relevant for payment and personal data. Mitigate by classifying data, encrypting it in transit and at rest with current algorithms, and managing keys properly.

5. Injection (A05)

Injection happens when untrusted input is interpreted as code or query logic: SQL injection, command injection, and cross-site scripting (XSS) all live here. Down from #3 thanks to safer frameworks, but still ubiquitous. Parameterized queries, output encoding, and input validation remain the fixes; here’s our guide to preventing JavaScript injection.

6. Insecure Design (A06)

Insecure design refers to flaws in the architecture itself (missing threat modeling, absent security requirements) that no amount of correct implementation can fix. A perfectly coded app can still be insecurely designed. Mitigate with threat modeling, secure design patterns, and security requirements set before development starts.

7. Authentication Failures (A07)

Authentication failures let attackers assume other users’ identities: credential stuffing, weak or missing MFA, flawed session management. Renamed from “Identification and Authentication Failures” to sharpen the focus. Mitigate with MFA, rate limiting, strong session handling, and breached-password checks.

8. Software or Data Integrity Failures (A08)

Software or data integrity failures occur when code and infrastructure trust updates, plugins, or data without verifying them: insecure CI/CD pipelines, unsigned updates, insecure deserialization. Unchanged at #8, and increasingly the mechanism behind supply chain attacks: trusted code that quietly becomes something else. Verification of what code does, not just where it comes from, is the emerging answer; more below.

9. Security Logging & Alerting Failures (A09)

Security logging and alerting failures mean breaches happen without detection, escalation, or response; the category was renamed in 2025 to stress that logs nobody acts on have almost no value. With just 723 mapped CVEs against a 3.91% incidence rate, it’s systematically underreported: you can’t file a CVE for the alert that never fired. Mitigate by logging security-relevant events, alerting on them in real time, and covering the surfaces that produce no logs at all.

10. Mishandling of Exceptional Conditions (A10)

Mishandling of exceptional conditions is the newest category: improper error handling, failing open, verbose error messages that leak internals, and logic that breaks down in unexpected states. It maps 24 CWEs, from NULL pointer dereferences to “failure to fail securely.” Mitigate by designing for failure: catch exceptions deliberately, fail closed, and keep error detail out of user-facing responses.

Your Third-Party Code Isn’t One OWASP Risk: It’s Four

Here’s what the official documentation won’t tell you. When OWASP ranked Software Supply Chain Failures third, it put third-party code at the center of the security conversation. But most of that code isn’t a dependency in your build so much as the scripts, tags, and trackers running live in your users’ browsers: the half of the supply chain your scanners never see. And a compromised script there isn’t only a supply-chain failure (A03). It’s also a security misconfiguration (A02), an integrity failure (A08), and a detection failure (A09), all at once.

That’s also why A03 is such a strange category: the highest average incidence rate on the list, 5.72%, yet only 11 CVEs map to its underlying weaknesses, and a scanner can’t scan for a signature that hasn’t been written. A year on from the list’s debut, the practical lesson is that behavior-based monitoring of this one layer covers four categories at once.

How One Compromised Script Fails Four OWASP Categories at Once

Picture a payment page that loads a script from a vendor you’ve used for years: a chat widget, say, or an analytics tag. Here’s how a single compromise of that one script lands in four different OWASP categories at the same time.

One day, the vendor’s CDN serves a new version of the file. Nothing about it looks wrong, because the domain is the same one you allowlisted long ago, and your Content Security Policy waves it through because the source is still permitted. That’s the supply-chain failure (A03): a component you depend on has been turned against you upstream, where you have no visibility.

Then it goes rogue, reading the card number and CVV as the customer types them in, then beaconing them to an attacker-controlled domain. It can do this because the script was loaded at checkout with full access to the DOM and nothing scoping it to what it actually needs. That’s the security misconfiguration (A02): over-privileged code on your most sensitive page, governed by no one.

The file’s hash changed, but nothing flagged it, because trusted origins don’t get re-verified. Approved code is free to become something else: the integrity failure (A08).

And for weeks, nobody knows. The malicious code runs in the customer’s browser, so it never touches your servers and never reaches your SIEM. There are no logs to miss, because there were no logs. That’s the logging and alerting failure (A09): the incident with no witness.

One script really can span four categories. Here’s how each one gets solved.

A03 · Software Supply Chain Failures: The Half Most Tools Skip

Most of the tooling aimed at A03 (software composition analysis, SBOM generation, dependency scanning) works from manifests and checks your dependencies before deployment. That’s real, valuable work, and it covers the build-time, server-side portion of the category. But those tools never see the client-side half, even though OWASP’s own A03 guidance is explicit that you must continuously inventory “both client-side and server-side components.”

That half is where the real incidents keep showing up. It’s where Polyfill.io happened: in 2024, a trusted CDN script was turned malicious across more than 100,000 sites at once. It’s where the June 2026 Polymarket compromise happened too: a poisoned third-party script drained roughly $3 million from users, with nothing server-side breached at all.

Closing it means continuously monitoring every first-, third-, and fourth-party script actually executing on your live pages: the runtime complement to the build-time scanning you already run. That’s the core of what Reflectiz does, including AI-driven deobfuscation of suspicious JavaScript so hidden payloads don’t have to be reverse-engineered by hand.

A02 · Security Misconfiguration: The Second-Place Risk Hiding in Your Tag Manager

Security Misconfiguration didn’t climb to second place because people keep leaving servers on default passwords. It got there because modern web pages are assembled from dozens of third-party pieces, each added by a different team for a different reason, most of them never inventoried and none governed. A misconfiguration here might be an analytics tag with access to the whole DOM on your payment page, a tag manager that lets marketing drop a script into checkout without security ever seeing it, or a Content Security Policy so permissive it allows anything. None of these needs a clever exploit.

The fix is governance of the third-party layer itself: a live inventory of every script, tag, and app on your pages, a baseline of approved behavior, and alerts when something new appears or deviates, with CSP enforcement when it does. (Reflectiz automates exactly this, down to pushing blocking rules through a WAF API when it detects a malicious domain.)

A08 · Software or Data Integrity Failures: When Approved Code Goes Bad

The hardest client-side compromise to catch is the one that arrives through a script that’s already trusted. When the vendor’s CDN serves a new version, the origin is still on the allowlist, the changed hash looks legitimate, and the CSP has no reason to intervene. Allowlists were never built to answer the question that actually matters here: not “is this source permitted?” but “is this code still doing what we approved?”

That question can only be answered by watching execution, not checking a manifest. Behavioral monitoring establishes a baseline of what each component is supposed to do and flags when a trusted script departs from it, the one signal an integrity failure reliably produces. It’s the difference between verifying where code came from and verifying what it does, and it’s what Reflectiz watches for continuously on live pages.

A09 · Security Logging & Alerting Failures: The Incident With No Witness

OWASP renamed this category in 2025 to put the emphasis on alerting, and the point behind the rename is blunt: logs nobody acts on have almost no value. The client side is where that failure is most complete, because for most organizations there are no logs at all. The code runs in the user’s browser, so your SIEM never sees it. That’s how the Magecart skimming network uncovered by Silent Push in early 2026 ran undetected for roughly four years. It wasn’t sophisticated: it simply deleted itself whenever it detected the site’s admin was logged in. Nobody was watching the surface it ran on.

The answer is a witness for that surface: continuous client-side monitoring with prioritized alerts, feeding the tools your team already uses (Splunk, your SIEM or SOAR, Jira) so the one change that matters isn’t buried under noise. Reflectiz does this through a bi-directional API.

Four Categories, One Control

Notice what these four have in common. A03, A02, A08, and A09 are usually treated as separate problems handled by separate tools: an SCA scanner, a config-hardening checklist, an integrity control, a logging platform. But on the third-party code layer they’re four views of a single problem: code you didn’t write, running where you can’t see, changing without warning, with no one watching. A tool that manages only one of those views is missing most of the picture.

That’s the case for treating the client-side third-party layer as its own control rather than a footnote under “supply chain.” And it’s increasingly not optional. PCI DSS 4.0.1’s requirements 6.4.3 and 11.6.1, mandatory since March 31, 2025, already demand exactly this for payment pages: an authorized inventory of every script, and tamper detection for when one changes. The regulation arrived at the same surface OWASP’s four categories converge on, just from a different direction.

The Other Six: Test the Code You Did Write

Monitoring solves the four categories that converge on code you didn’t write. But the rest of the list (Broken Access Control at #1, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Mishandling of Exceptional Conditions) lives mostly in code you did write, and those flaws don’t announce themselves. An IDOR, a privilege-escalation path, a business-logic hole: none of these shows up in a CVE feed or a scanner signature. You find them the way an attacker does: by probing the running application.

That used to mean an annual pentest, which is a poor match for a list built around continuous change. The emerging answer is continuous agentic pentesting: AI agents that map your attack surface, run every applicable attack category against every endpoint (access control, injection, authentication, error handling), independently validate each finding, and prove coverage with a full test matrix. It’s the offensive complement to continuous monitoring, and it’s how testing keeps pace with the OWASP list between releases. (For the wider landscape, here’s our comparison of the top agentic web-app pentesting tools of 2026.)

The Bottom Line

If your third-party risk lives entirely under “supply chain” on your register, you’ve named a real problem and under-scoped it by three-quarters. The scripts running in your users’ browsers are simultaneously a supply-chain exposure, a misconfiguration, an integrity risk, and a detection gap (A03, A02, A08, and A09), and the only way to cover all four is to watch that code as it actually executes. That’s the defensive half. The six categories in your own code need the opposite treatment: continuous attack, not observation.

That’s what Reflectiz does: continuous, agentless visibility into every third-party script on your live pages, with the behavioral baselines, integrity monitoring, policy enforcement, and alerting that turn four OWASP categories from four blind spots into one covered surface. And with the Offensive Hub running continuous agentic pentesting against the categories monitoring can’t see, the whole Top 10 sits under one roof. See every script running on your payment pages today. Book a Reflectiz exposure assessment.