OWASP Top 10 2025: What Changed, and Which Risks a Scanner Can Catch

What is the OWASP Top 10 2025?

The OWASP Top 10 2025 is a ranked list of ten categories of web application risk, each grouping related CWE weaknesses. For this edition OWASP analysed 589 CWEs and kept 248 of them in the ten categories, with a cap of 40 per category. Eight categories come from testing data donated by companies such as Semgrep, Sonar, Veracode, Contrast Security and Bugcrowd. The other two come from a community survey, because OWASP considers the data alone incomplete.

Security teams use the list as a shared vocabulary. Training, code review checklists, scanner reports and audit evidence are often organised by its categories, which is why a new edition ripples into tools, policies and audits.

What are the ten categories?

The ten categories of the OWASP Top 10 2025 are Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions.

What changed since the 2021 list?

Four changes matter for a development team: the supply chain gets its own category, SSRF moves into access control, error handling becomes a category, and misconfiguration rises to second place.

• Software Supply Chain Failures (A03). The 2021 category Vulnerable and Outdated Components covered known CVEs in your dependencies. The 2025 category covers "breakdowns or other compromises in the process of building, distributing, or updating software", and OWASP names "your build server & CI/CD" among the things to protect. A scan of your lockfile is no longer the whole answer: the pipeline that builds your code is in scope too. OWASP's background notes give this category the highest average incidence rate of the ten.
• SSRF joins Broken Access Control (A01). Server-side request forgery was A10 in 2021. It now counts as one of the 40 weaknesses of Broken Access Control.
• Mishandling of Exceptional Conditions (A10). The new category is about programs that "fail to prevent, detect, and respond to unusual and unpredictable situations". Among its 24 weaknesses: error messages that leak sensitive data (CWE-209), NULL pointer dereferences (CWE-476) and code that fails open instead of failing securely (CWE-636).
• Security Misconfiguration (A02) climbs from fifth to second. OWASP's definition now names cloud services alongside systems and applications set up incorrectly.

Two names change: Identification and Authentication Failures becomes Authentication Failures, and Security Logging and Monitoring Failures becomes Security Logging and Alerting Failures. Denial of service, renamed Lack of Application Resilience, sits in OWASP's "next steps" section, outside the ten.

Which open source scanner catches each risk?

Open source static scanners cover Injection and Cryptographic Failures widely, six other categories in part, and little of Insecure Design and of Security Logging and Alerting Failures. The table is our reading of each tool's documented scope against OWASP's own category pages, read on 13 November 2026.

Opengrep, the LGPL-2.1 fork of Semgrep, covers more than 30 languages and runs Semgrep rules unchanged. Its README describes taint analysis inside a file, which is why the Injection row says "flows that cross files". Trivy reads dependencies, infrastructure as code, secrets and licences, and our test of open source SCA tools shows what it and OSV-Scanner find on a real lockfile. Gitleaks finds passwords, API keys and tokens in files and git history; hard-coded credentials (CWE-798) belong to A07 in the 2025 list, and our comparison of open source secret scanners covers it in depth. zizmor is a static analyser for GitHub Actions, with audits such as template-injection, unpinned-uses, dangerous-triggers, excessive-permissions and cache-poisoning, which reach into A03 and A08.

None of these tools sees a malicious package that has no advisory yet, the gap that slopsquatting, the attack on package names an AI model invents, goes through.

Why do scanners miss the number one risk?

Static scanners miss the heart of Broken Access Control because the flaw is a missing check, and a missing check has no pattern. A scanner can follow user input to a dangerous function. It has no source for the rule that an invoice belongs to one customer.

The rule sets show it. On 13 November 2026 we counted the rules of the Opengrep community rule set, a snapshot of Semgrep's rules from January 2025: 2,007 rules, of which 1,354 carry a 2021 OWASP category. Injection has 384 of them. Broken Access Control has 228, but 114 of those check access settings of cloud resources, mostly in Terraform, and others cover path traversal, CSRF and open redirects. The three weaknesses that describe authorization itself, CWE-639 (authorization bypass through a user-controlled key), CWE-862 (missing authorization) and CWE-863 (incorrect authorization), appear in four rules. Three of them read application code, each for one framework: an unscoped find in Ruby on Rails, an ASP.NET Core controller with no authorization attribute, native data operations in Salesforce Apex. They spot a check that is absent; none can tell whether a check that is present is the right one.

OWASP said the same thing in 2017, when it wrote that "SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present." Here is what that looks like in an Express route:

// GET /api/invoices/:id
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

The route requires a login, the query is parameterised, the input never reaches a dangerous function. A scanner has nothing to flag. Yet any logged-in customer can read any invoice by changing the number in the URL, an insecure direct object reference. The fix is one condition, where: { id: req.params.id, customerId: req.user.customerId }, and only someone who knows that invoices belong to customers can write it.

Insecure Design is further out of reach. OWASP's page puts it plainly: "An insecure design cannot be fixed by a perfect implementation as needed security controls were never created to defend against specific attacks." A checkout that accepts a negative quantity passes every scanner, as our walk through the $0 cart shows. We cover the whole family in business logic flaws in AI-generated code.

How do you test for broken access control?

You test broken access control with a test that tries the forbidden action and expects a refusal, one per role and per object that belongs to someone. OWASP's 2025 page asks for exactly that: "Developers and QA staff should include functional access control in their unit and integration tests."

test("a customer cannot read another customer's invoice", async () => {
  const res = await request(app)
    .get(`/api/invoices/${aliceInvoice.id}`)
    .set("Authorization", tokenFor(bob));
  expect(res.status).toBe(404);
});

Such a test is both the proof and the guard. Before the fix it fails, which proves the flaw exists in your code and not in theory. After the fix it passes, and it stays in the suite so the next change cannot reopen the hole. The cost is knowing which objects belong to whom, which is the knowledge a scanner lacks.

Three habits go a long way:

1. Deny by default. Every new route starts closed, and access is granted by an explicit check that names the owner or the role.
2. Scope every query to the user. Look up records through the current user or tenant, never by a bare identifier from the request.
3. One refusal test per sensitive object. Invoices, documents, accounts, anything with an owner gets a test where the wrong user is refused.

What does the OWASP Top 10 mean when AI agents write the code?

The categories do not change when coding agents such as Claude Code, Cursor, GitHub Copilot or OpenAI Codex write the code, but the volume and the speed do. A team that ships more changes a week needs the scanners on every change, and needs the access checks reviewed on every new endpoint, because an agent writes a working route as easily as it skips an owner check that was never described to it.

The same agents can also do the defensive work. An agent that reads the codebase can map every endpoint, ask which roles reach each one, write the refusal test, run it and show whether it fails. That is the part of the OWASP Top 10 that scanners leave on the table, and it is work a coding agent can do at the speed it writes code. Our guide to AI coding agent security covers the other side: what the agent itself is allowed to run.

Where does CybeDefend fit?

CybeDefend Open Source is launching soon, and it covers both halves of this article. One command in your coding agent, /cybedefend, runs a full audit in two layers. First the AppSec scanners, open source, with Opengrep, Trivy, Gitleaks and zizmor among them, for code, dependencies, secrets, infrastructure as code, CI/CD and containers: the pattern-shaped risks of the table above. Keep the ones you want and add your own.

Then the AI scanner, run by your coding agent. Scanners match patterns. The AI scanner reads what your code is meant to do and finds where it breaks, in business logic, in access rights and in the flaws that only show when the code runs: the A01, A06 and A07 rows. It proves each flaw with an exploit written as a test in your own suite, like the one above. No extra model and no API key: the AI is the coding agent you already run.

Under both layers sits our whole platform, an agentic ASPM. It keeps every finding in one queue, and its security reports map findings to the OWASP Top 10 and the CWE Top 25. To run the audit on your own code when it opens, join the CybeDefend Open Source waitlist.

Frequently asked questions

What is new in the OWASP Top 10 2025?

Two categories are new: Software Supply Chain Failures at A03, which extends the old Vulnerable and Outdated Components to build systems and CI/CD, and Mishandling of Exceptional Conditions at A10. Server-side request forgery moved into Broken Access Control, and Security Misconfiguration rose from fifth to second.

What is number one in the OWASP Top 10 2025?

Broken Access Control, as in 2021. It groups 40 weaknesses, from path traversal and CSRF to missing authorization and insecure direct object references, and since 2025 it also includes SSRF.

Is SSRF still in the OWASP Top 10?

Yes, inside A01 Broken Access Control. SSRF was its own category, A10, in 2021; the 2025 edition rolled it into access control.

Can a SAST tool cover the whole OWASP Top 10?

No. A SAST tool covers Injection and Cryptographic Failures well and parts of several other categories. Dependency and pipeline risks need an SCA tool and a CI/CD scanner, and broken access control and insecure design need tests and review by someone who knows the rules of the application.

How often is the OWASP Top 10 updated?

There is no fixed schedule. The 2025 edition is the eighth, four years after the 2021 list.

Is CybeDefend open source?

Its open source edition, CybeDefend Open Source, is launching soon: our whole platform, an agentic ASPM, free to run on your own servers. The command /cybedefend chains the open source AppSec scanners and an AI scanner run by your coding agent, and keeps every finding in one queue. Join the CybeDefend Open Source waitlist.