What the OWASP Top 10 is and what it is not
The Open Worldwide Application Security Project (OWASP) is a non-profit foundation. Its best-known publication is the OWASP Top 10: a list of the ten most important security risks for web applications. It is based on test data contributed by companies and reviewers and on a survey of practitioners.
OWASP itself calls the list an awareness document. It is meant to show developers, architects and managers where the biggest risks lie. What it is not:
- Not a certification. There is no OWASP seal and no OWASP compliance. Anyone who wants to sell you one is selling something else.
- Not a complete test catalogue. For detailed requirements there is the OWASP Application Security Verification Standard (ASVS).
- Not a law. But a widely used benchmark for what “state of the art” means for web applications.
The list is useful for you as a decision-maker all the same: in ten points, it shows where applications are most often and most seriously vulnerable. And it gives you a common language with your team and your service providers.
What changed in 2025
The 2025 edition replaces the 2021 version. According to OWASP, there are two new categories and one merger:
- New: software supply chain failures (A03). It extends the former category “outdated components” to everything that can go wrong between dependencies, build systems and delivery. The practitioners in the survey voted for it by a large majority.
- New: mishandling of exceptional conditions (A10). Error handling, logic errors and systems that fail “open” instead of “closed” when something goes wrong.
- Merged: Server-Side Request Forgery (SSRF), still a category of its own in 2021, now belongs to broken access control (A01).
- Moved up: security misconfiguration jumps from rank 5 to rank 2. More and more of an application’s behaviour lives in configuration rather than in code.
The basis has become broader: OWASP analysed 589 weakness types (CWEs), compared with just under 400 in 2021. Eight categories come from the data, two from the survey, because some risks hardly appear in test data.
For you, this means: if your last security report is still structured according to the 2021 list, it lacks mainly the supply chain and the handling of exceptional conditions. Both deserve a look of their own, especially for software with many dependencies or with code from AI assistants.
The ten risks at a glance
For each risk you will find three things: what it is, what it can cost your company, and the one question to ask your team. All examples are fictional.
A01: Broken access control
What it is: Users can see data or perform actions they are not authorised to.
What it costs (example, fictional): A customer portal shows invoices under a sequential number. A customer changes the number in the address bar and sees other customers’ invoices. A report to the data protection authority follows, letters to everyone affected, and a major customer who reviews its contract.
The question for your team: “On every access, does our server check whether this user may see exactly this record, or do we rely on nobody changing the address?”
A02: Security misconfiguration
What it is: Insecure default settings, open admin interfaces, verbose error messages or missing protection mechanisms in server, framework or cloud.
What it costs (example, fictional): A storage bucket with backups is accidentally publicly readable. Nobody notices until a security researcher gets in touch. Whether someone else had already downloaded the data before that can no longer be established.
The question for your team: “Who checks that our configuration in production is as secure as planned, and how often?”
A03: Software supply chain failures
What it is: Vulnerabilities or malicious code that enter your software through libraries, tools, build systems or updates.
What it costs (example, fictional): A popular open-source package receives a manipulated update. Your build pipeline pulls it automatically, and a few days later your application delivers malicious code to your own customers.
The question for your team: “Do we know which components in which versions are in our software, and how do we find out about a new vulnerability in them?”
A04: Cryptographic failures
What it is: Sensitive data is not encrypted, is encrypted incorrectly or with outdated methods, or keys are left unprotected.
What it costs (example, fictional): Passwords are stored using an outdated method. After a data leak, they can be read in plain text within a short time, and because many users reuse passwords, the damage also reaches other services.
The question for your team: “Which sensitive data do we store, how is it encrypted, and where are the keys?”
A05: Injection
What it is: User input is executed as a command, for example as a database query or as a script in other users’ browsers.
What it costs (example, fictional): A search field in an online shop inserts the input directly into a database query. An attacker uses it to read out the entire customer table, including addresses and order history.
The question for your team: “Do we use parameterised queries and consistent output encoding everywhere, or are there places where input is processed directly?”
A06: Insecure design
What it is: The weakness is not in a line of code but in the concept: a workflow was never thought through with misuse in mind.
What it costs (example, fictional): A voucher system checks every code but does not limit how often an account may try codes. A script finds hundreds of valid vouchers overnight.
The question for your team: “For our most important workflows, have we considered how someone could abuse them, and documented it?”
A07: Authentication failures
What it is: Weaknesses in login and sessions: weak password rules, no protection against mass guessing, sessions that never expire.
What it costs (example, fictional): Attackers automatically test credentials from other companies’ data leaks against your login. Without a limit on attempts, they take over dozens of customer accounts and order at their expense.
The question for your team: “What happens if someone tries to log in a thousand times a minute, and do we offer two-factor authentication?”
A08: Software or data integrity failures
What it is: The application trusts code, updates or data without checking that they come unchanged from a trustworthy source.
What it costs (example, fictional): The website embeds a script from a third-party server. The server is compromised, and from then on the script reads payment data in the order form.
The question for your team: “Do we check that updates, scripts and data from outside have not been tampered with before we use them?”
A09: Security logging and alerting failures
What it is: Security-relevant events are not logged, or nobody looks because no alert is triggered.
What it costs (example, fictional): An attacker tries out access for weeks. The logs show it, but nobody is notified. You only notice the incident when a customer calls, and the deadline for reporting to the authority is already close.
The question for your team: “How would we recognise an attack in progress, and who gets a message, and how quickly?”
A10: Mishandling of exceptional conditions
What it is: The application reacts wrongly to the unexpected: errors are swallowed, checks are skipped or internal details are revealed.
What it costs (example, fictional): If the service for permission checks fails briefly, the application lets all requests through when in doubt. For a few minutes, every user is an administrator.
The question for your team: “What does our application do when a service, a database or a check fails: block or let through?”
How to interpret your team’s answers
You do not have to understand the technical details to tell good answers from weak ones. Three patterns help:
- Good answers are specific. “Every query goes through our authorisation module, and there are tests that check that user A cannot see user B’s data” is a good answer. “The framework does that” is a hope.
- Good answers name a process. Whoever has dependencies checked automatically for known vulnerabilities, applies updates regularly and knows who decides in an emergency has a process. Whoever says “We update when something comes up” does not.
- Good answers know their limits. A team that says “We have never checked that” is honest and therefore a good starting point. Be cautious if every question is answered with “That is not an issue for us.”
Pay particular attention to inherited code, for example from an agency or an acquisition, and to code that was largely written with AI assistants. In both cases, often nobody on the team knows every part in detail. The ten questions then quickly show where knowledge is missing.
And one more note: the questions are not a vote of no confidence in your team. Good developers are glad when management takes security seriously, because then they get time and budget for it. Ask the questions openly, not as an exam. Keep the answers in writing: they are the starting point for any later review and show in a year what has improved.
Which check finds which risk
No single check covers all ten risks. The table shows honestly what each of our packages sees. Some risks only become visible in a code or architecture review.
| Risk | Security check (from outside) | App audit (with login) | Code audit (source code) |
|---|---|---|---|
| A01 Access control | no | largely | largely |
| A02 Misconfiguration | partly | partly | partly |
| A03 Supply chain | partly | partly | largely |
| A04 Cryptography | partly | partly | largely |
| A05 Injection | no | largely | largely |
| A06 Insecure design | no | partly | partly |
| A07 Authentication | partly | largely | largely |
| A08 Integrity | partly | partly | largely |
| A09 Logging and alerting | no | no | partly |
| A10 Exceptional conditions | partly | partly | largely |
Largely: typical patterns of this category are checked. Partly: only individual aspects are visible. No check finds every vulnerability in a category.
Some explanations:
- The security check only sees what every browser sees: encryption, security headers, cookies, exposed files and visible versions. That is a good first look, but it ends at the login.
- The app audit tests with two test accounts whether user A sees user B’s data, whether sessions are secure and whether inputs and interfaces can be attacked.
- The code audit finds causes that are invisible from outside: dependencies with known vulnerabilities, keys in the code, missing checks in rarely used paths.
- Insecure design and alerting can only partly be read from the code. Whether a workflow can be abused and whether someone responds to an alert at night is clarified by a conversation about architecture and operations. For larger organisations we offer a security architecture review for this.
The full audit combines app and code audit, the findings can confirm each other, and an expert signs off every one. Our methodology shows how we proceed.
Where a code audit ends and a penetration test begins is shown in our comparison Code audit or penetration test.
OWASP, NIS2, CRA and GDPR
No law prescribes the OWASP Top 10. Several regulations do require security in line with the state of the art, though, and the Top 10 is a widely used benchmark for that:
- NIS2 obliges affected entities to take risk management measures, explicitly including security in the development and maintenance of systems and the handling of vulnerabilities. In Germany this has applied since 6 December 2025 through Section 30 BSIG; in France, implementation is still in the legislative process (as of November 2026).
- The Cyber Resilience Act (CRA) requires manufacturers of products with digital elements, from 11 December 2027, to ship without known exploitable vulnerabilities and to handle vulnerabilities throughout the life cycle. The reporting obligations have applied since 11 September 2026; more on this in our article on the reporting obligation under the Cyber Resilience Act.
- Article 32 GDPR requires appropriate technical and organisational measures and a process for regularly testing their effectiveness.
An audit against the OWASP Top 10 is not a certificate and not a conformity assessment. It does document that you have reviewed your application against a recognised benchmark and prioritised the findings. In our experience, customers, auditors and insurers ask for this more and more often.
Three steps for this week
- Get the view from outside. Have your most important website or web app checked with our free security check. You usually receive a grade from A to F and the findings by severity within 2 hours on working days.
- Ask three questions. Take the questions on A01, A02 and A03 into your next conversation with your team or agency. If the answers are hesitant, you know where to start.
- Decide the depth of review. For applications with a login, we recommend the app audit at €490 net, for your own or inherited code the code audit at €890 net. Both together, with expert sign-off of every finding, is the full audit at €1,690 net.
All prices are net plus VAT. Our services are aimed exclusively at businesses.
The first step costs nothing
The security check is free and passive: we attack nothing and need no login. It shows you which of the ten risks are already visible from outside, and afterwards we tell you honestly whether and which audit is worth it for you.
What an audit costs and how to compare quotes is covered in What does a code audit cost?
OWASP® is a registered trademark of the OWASP Foundation. We are not affiliated with the OWASP Foundation; it neither endorses nor certifies our services.