What the OWASP Top 10 is and 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 testers, and on a survey among 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 trying 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 yardstick for what “state of the art” means for web applications.
As a decision maker you still benefit from the list: 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 consolidation:
- New: software supply chain failures (A03). It extends the former category “vulnerable and outdated components” to everything that can go wrong across dependencies, build systems and distribution. 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 “fail closed” when something goes wrong.
- Consolidated: server-side request forgery (SSRF), a category of its own in 2021, is now part of broken access control (A01).
- Moved up: security misconfiguration jumps from fifth to second place. More and more of an application’s behaviour lives in configuration rather than code.
The basis has grown: OWASP analysed 589 weakness types (CWE), up from almost 400 in 2021. Eight categories come from the data, two from the survey, because some risks barely show up in test data.
The ten risks at a glance
For each risk you get three things: what it is, what it can cost your business, and the one question to ask your team. All examples are fictitious.
A01: Broken access control
What it is: users can see data or perform actions they are not authorised for.
What it costs (fictitious example): a customer portal shows invoices under a sequential number. A customer changes the number in the address bar and sees other customers’ invoices. What follows is a report to the data protection authority, letters to everyone affected and a key account reviewing its contract.
The question for your team: “Does our server check on every request whether this user may see exactly this record, or do we rely on nobody changing the address?”
A02: Security misconfiguration
What it is: insecure defaults, exposed admin interfaces, verbose error messages or missing protections in the server, framework or cloud.
What it costs (fictitious example): a storage bucket with backups is accidentally publicly readable. Nobody notices until a security researcher gets in touch. Whether someone else downloaded the data before can no longer be established.
The question for your team: “Who checks that our production configuration is as secure as planned, and how often?”
A03: Software supply chain failures
What it is: vulnerabilities or malicious code that reach your software through libraries, tools, build systems or updates.
What it costs (fictitious example): a popular open-source package receives a tampered update. Your build pipeline pulls it in automatically, and a few days later your application serves malicious code to your own customers.
The question for your team: “Do we know which components in which version are in our software, and how do we learn about a new vulnerability in them?”
A04: Cryptographic failures
What it is: sensitive data is not encrypted, encrypted incorrectly or with outdated methods, or keys are left unprotected.
What it costs (fictitious example): passwords are stored with an outdated method. After a data breach they are readable in plain text within a short time, and because many users reuse passwords, the damage spreads to 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 (fictitious example): a search field in an online shop inserts the input directly into a database query. Through it, an attacker reads 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 passed on directly?”
A06: Insecure design
What it is: the weakness is not in a line of code but in the concept: a process was never thought through for abuse.
What it costs (fictitious example): a voucher system checks every code but does not limit how many codes an account may try. A script finds hundreds of valid vouchers overnight.
The question for your team: “Have we thought about how our most important processes could be abused, 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 (fictitious example): 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 place orders 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 are unchanged and come from a trusted source.
What it costs (fictitious example): the website embeds a script from a third-party server. The server is compromised, and from then on the script skims payment data in the checkout form.
The question for your team: “Do we verify that updates, scripts and external data 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 raised.
What it costs (fictitious example): an attacker tries accounts for weeks. The logs show it, but nobody is notified. You only notice the incident when a customer calls, and by then the deadline for reporting it to the authority is already tight.
The question for your team: “How would we recognise an ongoing attack, and who gets notified, how quickly?”
A10: Mishandling of exceptional conditions
What it is: the application reacts wrongly to the unexpected: errors are swallowed, checks skipped or internal details revealed.
What it costs (fictitious example): when the permission service is briefly down, the application lets every request through by default. 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 judge your team’s answers
You do not need to understand the technical details to tell good answers from weak ones. Three patterns help:
- Good answers are concrete. “Every query goes through our permission module, and there are tests that check user A cannot see B’s data” is a good answer. “The framework handles that” is a hope.
- Good answers name a process. A team that has dependencies checked automatically for known vulnerabilities, applies updates regularly and knows who decides in an emergency has a process. “We update when something comes up” is not one.
- Good answers know their limits. A team that says “We have never checked that” is honest, and that is a good starting point. Be careful when 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 written largely with AI assistants. In both cases, often nobody on the team knows every part in detail. The ten questions quickly show where knowledge is missing.
One more thing: 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. So ask openly, not as an exam. Write the answers down: they are the starting point for any later review and show a year from now what has improved.
Which check finds which risk
No single check covers all ten risks. The table honestly shows 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 some aspects are visible. No review finds every weakness in a category.
A few notes:
- The security check only sees what any browser sees: encryption, security headers, cookies, exposed files and visible versions. A good first look, but it stops at the login.
- The app audit uses two test accounts to check whether user A can see 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 process can be abused and whether someone reacts to an alert at night is a matter for 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 approves every one of them. How we work is explained in our methodology.
Where a code audit ends and a penetration test begins is shown in our comparison of code audit and penetration test.
OWASP, NIS2, CRA and GDPR
No law prescribes the OWASP Top 10. Several regulations do require state-of-the-art security, though, and the Top 10 is a widely used yardstick for it:
- NIS2 requires entities in scope to take risk management measures, explicitly including security in the development and maintenance of systems and vulnerability handling. In Germany this has applied since 6 December 2025 through Section 30 BSIG; in France, transposition was still going through Parliament as of November 2026.
- The Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to ship without known exploitable vulnerabilities from 11 December 2027 and to handle vulnerabilities over the whole life cycle. The reporting obligations have applied since 11 September 2026; more in our article on reporting under the Cyber Resilience Act.
- Article 32 GDPR requires appropriate technical and organisational measures and a process for regularly testing their effectiveness.
An audit along the OWASP Top 10 is neither a certificate nor a conformity assessment. It does document that you have checked your application against a recognised yardstick and prioritised the findings. In our experience, customers, auditors and insurers ask for exactly that 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. Usually within 2 hours on working days, you receive a grade from A to F and the findings by severity.
- 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 on the depth. For applications with a login we recommend the app audit for €490 net, for your own or inherited code the code audit for €890 net. Both together, with an expert approving every finding, is the full audit for €1,690 net.
All prices net, plus VAT. Our offers are for businesses only.
The first step costs nothing
The security check is free and passive: we attack nothing and need no login. It shows which of the ten risks are already visible from outside, and afterwards we tell you honestly whether an audit is worth it for you, and which one.
What an audit costs and how to compare quotes is explained in how much does a code audit cost?
OWASP® is a registered trademark of the OWASP Foundation. We are not affiliated with the OWASP Foundation, which does not endorse or certify our services.
Frequently asked questions
Must my application be OWASP compliant?
There is no OWASP compliance and no OWASP certificate. The Top 10 is an awareness document. Customers, auditors and laws such as NIS2 (in Germany Section 30 BSIG), the Cyber Resilience Act or Article 32 GDPR do require state-of-the-art security, though, and the OWASP Top 10 is a widely used yardstick for it.
How often is the list updated?
Recently about every four years: the previous editions appeared in 2017 and 2021, the current one carries the year 2025. The risks do not disappear between editions; they only move up or down the ranking.
Does an automated scanner find all ten risks?
No. A scanner from outside mainly sees configuration, encryption and visible versions. Access control needs tests with a login, supply chain and cryptography show best in the code, and insecure design often only comes up in a conversation about the architecture.
Is an OWASP audit a penetration test?
No. “OWASP audit” only names the yardstick, not the method. Our app audit and code audit check along the OWASP Top 10 in an automated, AI-assisted way. A penetration test is a manual attack by a tester, which we do not offer.
This article was created with the help of automated research and AI. David Kreutzer reviewed it and approved it on 4 November 2026.
About the author
Managing Director, Viewconic GmbH
Leads the security and code audits at Viewconic and reviews every article on this blog before it is published.
Profile and all articles →