- The current edition is the OWASP Top 10:2025, checked on owasp.org on 18 October 2026.
- It names ten categories of risk to web applications. Each one is a product question too.
- Ask the ten questions, then decide which answers you want to hear next.
The OWASP Top 10 describes itself as “a standard awareness document for developers and web application security”, and it “represents a broad consensus about the most critical security risks to web applications”. The edition on owasp.org today is the 2025 version, OWASP Top 10:2025.
It is written for developers. But the list keeps turning up on a product leader’s desk: in a customer’s security questionnaire, in a procurement call, in the report from a penetration test. You don’t need to read code to use it. Each category is a question you can put to your team, and the answers tell you where your attention belongs.
Two things the list is not. It is not a checklist that makes a product secure once every box is ticked, and it is not a certification. It is a shared vocabulary, so that you and your team, and your customers, mean the same thing when you name a risk.
The ten categories, in plain terms
The names below are written as OWASP writes them, and each links to its page on owasp.org.
A01:2025 Broken Access Control. Access control makes sure users can’t act outside the permissions they are meant to have. When it breaks, one customer sees another customer’s invoices, or an ordinary user reaches an admin page. Ask: can each user reach only what is theirs, and how do we know?
A02:2025 Security Misconfiguration. OWASP describes this as a system, application or cloud service set up incorrectly from a security perspective. Defaults left on, a debug page left open, storage left public. The code can be sound and the product still exposed. Ask: are our settings safe as they ship, and who owns them?
A03:2025 Software Supply Chain Failures. In OWASP’s words, “breakdowns or other compromises in the process of building, distributing, or updating software”. Most products are built on code other people wrote. A weakness in any of it is a weakness in yours. Ask: do we know what our product is built on, and who keeps it current?
A04:2025 Cryptographic Failures. Sensitive data, such as passwords, payment details or health records, needs to be protected when it travels and where it is stored. This category covers the ways that protection is missing or too weak. Ask: which data is sensitive, and is it protected as it should be?
A05:2025 Injection. OWASP describes an application flaw that lets untrusted user input reach an interpreter. Put simply, something a user typed is treated as an instruction, not as text. Ask: can what a user types ever run as a command?
A06:2025 Insecure Design. OWASP calls this a broad category of “missing or ineffective control design”. The flaw is in the plan, not the build: a password reset that anyone can trigger for anyone, a discount with no limit. Perfect code can’t fix a design that never considered misuse. This is the category closest to a product leader’s own work. Ask: when we design a feature, do we plan for misuse, not only for use?
A07:2025 Authentication Failures. This is when a system can be tricked into accepting an invalid or incorrect user as legitimate. Sign-in, sessions and password recovery all sit here. Ask: can we trust who is signing in, and what happens when they sign out?
A08:2025 Software or Data Integrity Failures. OWASP describes code or data that is “invalid or untrusted” being treated as trusted and valid. An update nobody verified, or data accepted from outside and used as if it were your own. Ask: do we check code and data before trusting it?
A09:2025 Security Logging and Alerting Failures. OWASP’s page opens plainly: without logging and monitoring, attacks and breaches cannot be detected. The other nine categories are about keeping an attacker out. This one is about knowing they tried. Ask: would anyone notice an attack under way, and who would hear about it?
A10:2025 Mishandling of Exceptional Conditions. In OWASP’s words, programs that “fail to prevent, detect, and respond to unusual and unpredictable situations”. An error that shows internal details to a visitor, or a failure that leaves a door open instead of closed. Ask: when the unexpected happens, what does it do?
Using the questions
You don’t need all ten answers at once. Pick the categories that touch what your customers trust you with, and ask those first. A product that holds personal data starts with access control and cryptography. A product with many integrations starts with the supply chain and integrity.
Listen for answers that name an owner and something you could look at. “We think so” is a starting point, not an answer. And the list is not a ranking of what matters most for your product. That judgement stays yours.
If a penetration test has already handed you findings under these names, Fix what the penetration test found covers that situation.
Where we come in
We make no promise that a product is secure, and we hold no certification. The OWASP Top 10 is a way to ask better questions, not a guarantee.
If the questions turn up work you want done, we can take on the security work you choose on your product. Harden security before the questionnaire arrives shows what that looks like. We work within the access you grant, and nothing more. The work lands in your own code repository. The code we build for you is yours. You decide what ships. Nothing reaches your users without your approval.
It starts with a conversation, with no obligation.
