OWASP Top 10 Explained: A Developer's Guide for 2026

9 min read · Last updated: October 24, 2026

The OWASP Top 10 is a free list of the ten most critical web application security risks, published by the OWASP Foundation, a nonprofit. The current 2025 edition puts Broken Access Control at number one, and OWASP found some form of it in 100% of the applications tested. You do not need to be a security expert to use it.

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The article that started this

• Kheang Panda, "You Know How to Write Code, But Is Your Application Secure?", Medium, October 24, 2026

The primary source: OWASP Top 10:2025

• OWASP Top 10:2025, Introduction (the full list and methodology)
• A01:2025 Broken Access Control
• A03:2025 Software Supply Chain Failures
• A10:2025 Mishandling of Exceptional Conditions

The organization

• About the OWASP Foundation

On October 24, 2026, developer Kheang Panda published a short introduction to OWASP on Medium with a simple point: you can write clean, fast, well structured code and still ship an app that leaks every user's data. The fix is not a security degree. It is learning to see ten kinds of mistakes in your own code.

I agree with that, so here is the explainer I wish I had when I started. One comparison, how the list is built, when to use it and when not to, and a small piece of code you can copy.

Key takeaways

• The OWASP Top 10:2025 is the current edition. Broken Access Control is #1, found in some form in 100% of applications tested.
• Contributors donated data on over 2.8 million applications. 8 of the 10 categories come from that data, 2 from a community survey.
• Two categories are new in 2025: Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10).
• Security Misconfiguration jumped from #5 to #2. Injection dropped from #3 to #5.
• Authentication asks "who are you?" Authorization asks "what are you allowed to do?" Most of the #1 risk lives in the gap between them.

What is the OWASP Top 10?

The OWASP Top 10 is a ranked list of the ten most critical categories of web application security risk. It is published for free by the Open Worldwide Application Security Project (OWASP), a 501(c)(3) nonprofit foundation. Each category groups related weaknesses and explains how they happen, how attackers use them, and how to prevent them.

OWASP itself started on December 1, 2001, and was incorporated as the OWASP Foundation on April 21, 2004. According to its about page, it has 250+ chapters worldwide and 275+ active projects. The Top 10 is the one most developers have heard of.

Each entry has a code like A01:2025. The letter and number are its rank. The year tells you which edition you are reading. That matters, because the order changes between editions.

Think of your app as a hotel

The easiest way to understand application security is a hotel. Most security bugs are not exotic hacks. They are a hotel with good locks and a key card that opens the wrong doors.

When you arrive, the front desk checks your ID. That is authentication: proving who you are. Then they hand you a key card that opens room 412 and nothing else. That is authorization: deciding what you are allowed to do.

Now imagine the card opens any room, as long as you type a different room number into the lift panel. The front desk did its job perfectly. The hotel is still broken.

That is exactly the example Panda uses, with a hospital system instead of a hotel. A patient logs in, sees their record at a URL ending in their ID, changes the ID, and gets someone else's medical record. The language, the database and the framework are all fine. The authorization logic is missing.

OWASP describes the same thing in its #1 category. An app reads an account parameter from the URL, puts it straight into a database query, and never checks it. Change ?acct= to someone else's account and you are in.

A login screen proves who you are. It says nothing about which rooms you can enter.

What are the OWASP Top 10 2025 categories?

The 2025 list keeps Broken Access Control at number one, moves Security Misconfiguration up to two, and adds two new categories: Software Supply Chain Failures at three and Mishandling of Exceptional Conditions at ten. Server-Side Request Forgery (SSRF), a separate category in 2021, is now part of A01.

2025 rank	Category	What changed from 2021
A01	Broken Access Control	Stays #1. SSRF merged in
A02	Security Misconfiguration	Up from #5
A03	Software Supply Chain Failures	New. Expands "Vulnerable and Outdated Components"
A04	Cryptographic Failures	Down from #2
A05	Injection	Down from #3
A06	Insecure Design	Down from #4
A07	Authentication Failures	Stays #7. Renamed from "Identification and Authentication Failures"
A08	Software or Data Integrity Failures	Stays #8
A09	Security Logging and Alerting Failures	Stays #9. Renamed from "Security Logging and Monitoring Failures"
A10	Mishandling of Exceptional Conditions	New

Source: the OWASP Top 10:2025 introduction.

Panda's advice on this list is the right one: do not memorize it. Learn how each category shows up in real code you write.

How does OWASP build the Top 10?

OWASP builds the Top 10 from two inputs. Eight categories come from vulnerability data donated by security firms and contributors, covering over 2.8 million applications. The other two come from a community survey of practitioners, because OWASP says the data alone is incomplete and cannot see every newer risk.

Here is the process, step by step, as the 2025 introduction describes it:

1. Collect data. Contributors donate findings from testing their applications. For 2025 that covered over 2.8 million applications.
2. Map findings to CWEs. A CWE (Common Weakness Enumeration) is a standard ID for a type of weakness, like "missing authorization". The 2025 dataset contained 589 CWEs.
3. Group CWEs into categories. The ten categories together contain 248 CWEs. Broken Access Control alone holds 40.
4. Score them. OWASP adds exploit and impact data from roughly 175,000 National Vulnerability Database (NVD) records.
5. Pick eight from the data. OWASP states it only picks eight of the ten from data "because it's incomplete".
6. Pick two from the survey. Software Supply Chain Failures was "overwhelmingly voted a top concern", with exactly 50% of respondents ranking it #1. Logging and Alerting Failures was voted back in again.

Why the survey? Data comes from what tools can already find. A risk that is new, or hard to test automatically, will look small in the data long before it looks small in real attacks.

Why is Broken Access Control number one?

Broken Access Control is number one because it is everywhere. OWASP found some form of it in 100% of the applications tested, mapped to 40 CWEs, with 1,839,701 total occurrences and 32,654 related CVEs in its 2025 data. It is a missing check, not a clever exploit.

The common shapes are easy to recognize once you know them:

• Changing an ID in a URL or request to read someone else's data. This is called an insecure direct object reference (IDOR).
• Hiding admin pages in the front end only. OWASP's example: an admin page is hidden with JavaScript, and a plain curl request to the same endpoint walks straight in.
• APIs that check reads but not writes, so you cannot view a record but can still edit or delete it.
• Forced browsing, typing a privileged URL directly and finding nothing stops you.

Every one of these is a missing check in code a developer wrote. That is the good news. It means a developer can fix it.

What is new in 2025: supply chains and error handling

The two new categories are about code you did not write and paths you did not plan for. A03 covers compromises in how software is built, distributed or updated. A10 covers what your app does when something goes wrong: crashes, leaked error details, and "failing open" instead of failing safely.

A03, Software Supply Chain Failures, reaches beyond known vulnerable packages. OWASP's examples include SolarWinds, where a compromised vendor update reached roughly 18,000 organizations, and Shai-Hulud in 2025, described as "the first successful self-propagating npm worm", which reached over 500 package versions before npm disrupted it.

A10, Mishandling of Exceptional Conditions, is mapped to 24 CWEs. One OWASP example: a detailed database error shown to the user reveals system internals, which helps an attacker craft a better SQL injection. Another: a multi-step payment fails halfway, does not fully roll back, and money can move twice.

When should you use the OWASP Top 10, and when not?

Use the OWASP Top 10 as a learning map and a code review lens: it tells you which mistakes are most common and where to look first. Do not treat it as a complete security audit. It covers ten categories holding 248 of the 589 CWEs in OWASP's own dataset, and OWASP says that data is incomplete.

Use it for	Do not use it as
Learning security as a developer, one category at a time	Proof that your app is secure
A checklist when reviewing a pull request	A replacement for a penetration test on a high-risk app
Deciding what to fix first in an existing codebase	A full list of every weakness
Shared vocabulary with your team ("this is an A01 bug")	A ranking of what matters most for your specific app

My take: if your app handles payments, health data or anything regulated, the Top 10 is where you start, not where you stop. For a side project or an internal tool, getting A01, A02 and A05 right already closes most of the obvious ways in.

What does a broken access control fix look like in code?

The fix is to check ownership on the server, on every request, before returning or changing data. A login check is not enough. Below is a vulnerable Node.js and Express endpoint, then a fixed version, following the same pattern Panda shows: authenticate, verify ownership, return limited fields.

The vulnerable version. Any logged in user can read any invoice:

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

The attack is one line. Log in as yourself, then ask for someone else's ID:

curl -H "Cookie: session=YOUR_SESSION" https://example.com/api/invoices/1043

The fixed version. It scopes the query to the logged in user and returns only the fields the client needs:

app.get('/api/invoices/:id', requireLogin, async (req, res) => {
  const invoice = await db.invoices.findOne({
    id: req.params.id,
    ownerId: req.user.id,
  });

  if (!invoice) {
    return res.status(404).json({ error: 'Not found' });
  }

  res.json({ id: invoice.id, amount: invoice.amount, status: invoice.status });
});

Three things changed. The ownership check lives in the query, so a wrong ID simply finds nothing. The response says "Not found" instead of "Forbidden", so it does not confirm the invoice exists. And the full database row never leaves the server.

Add one more piece for A10, a global error handler that fails closed and never shows internals to the user:

app.use((err, req, res, next) => {
  logger.error(err);
  res.status(500).json({ error: 'Something went wrong' });
});

Panda also notes that real apps often need more: role based permissions, tenant level checks for multi-tenant products, and controlled admin access. Start with ownership. Add the rest when your app needs it.

How do you start with OWASP this week?

1. Read the A01 page. It is the one most likely to be in your code today.
2. Pick one API route that takes an ID. Log in as user A and request user B's record. If it works, you found your first bug.
3. Move every authorization check to the server. OWASP's advice is to deny by default and implement access control once, in one central place, then reuse it.
4. Run your dependency audit (npm audit, or your language's equivalent) as a first step on A03.
5. Add a test that asserts user A gets a 404 on user B's data, so the fix stays fixed. OWASP recommends access control tests in your unit and integration suites.

If AI tools write part of your code, this matters more, not less. Generated endpoints often check login and skip ownership. Our guide on how to review AI generated code without missing critical bugs covers that review step, and cybersecurity basics for developers goes wider than the web.

FAQ

What does OWASP stand for?

OWASP stands for the Open Worldwide Application Security Project. It is a 501(c)(3) nonprofit foundation that publishes free software security resources. The project started on December 1, 2001, and has 250+ chapters and 275+ active projects according to its own site.

Is the OWASP Top 10 2025 the latest version?

Yes. As of October 2026, OWASP Top 10:2025 is the current edition, and the official Top 10 site redirects to it. It replaced the 2021 edition, adding Software Supply Chain Failures and Mishandling of Exceptional Conditions, and merging SSRF into Broken Access Control.

What is the difference between authentication and authorization?

Authentication checks who a user is, usually with a login. Authorization checks what that user is allowed to do, such as which records they can read or change. Most Broken Access Control bugs happen when an app does authentication correctly and skips authorization.

Do I need to memorize the OWASP Top 10?

No. Knowing the names helps in conversations, but the value is in recognizing each risk in your own code. Learn one category at a time, find an example in a project you have built, and fix it.

Pick one endpoint that takes an ID and test it as another user today. For the rest of your workflow, try the free tools on Art of Code, and read why code was never the hard part.

Written by Adithya Guttha, Founder of Art of Code.