OWASP Top 10
OWASP / top ten web application security risks / application security risks
The OWASP Top 10 is a standard awareness document naming the most common security risks in web applications. It is not a certification and not a checklist a supplier can pass. NIST built its own development framework partly on it, which is why it works better as a question than as a requirement.
It describes itself carefully, and the wording is the point. The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. The current release is the 2025 version, which includes updates based on the latest data and security trends. So it is a consensus about risks, it changes, and awareness is the job it claims to do.
The 2025 list, in order, runs: 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. Reading the names is worth five minutes of anyone's time, because most of them describe decisions rather than code.
A standards body treats it as an input rather than as an exam. The NIST Secure Software Development Framework is a set of fundamental, sound, and secure software development practices based on established secure software development practice documents from organizations such as BSA, OWASP, and SAFECode. That is the relationship worth knowing. The Top 10 says what tends to go wrong. A framework says what a producer should do about it.
NIST also explains why neither is automatic. Few software development life cycle models explicitly address software security in detail, so practices like these have to be added to each implementation rather than assumed. And one sentence makes the whole thing useful to somebody buying rather than building. The framework provides a common language, so software producers and acquirers can use it to foster their communications for procurement processes.
In practice
The list is most useful read backwards. Rather than asking whether a supplier follows the Top 10, which invites a yes, ask them to describe their practice under the four groups NIST uses: preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities. The last one is the question most proposals never answer.
Not the same as
- A certification
- Nothing in the document certifies anyone. It is an awareness document by its own description, and there is no version of passing it.
- A complete list
- It is a consensus about the most critical risks, which means it is deliberately short. Something absent from it is not thereby safe.
Why it matters to you
You cannot review a supplier's code, and you can hear how they talk about risk. This is the vocabulary that makes that conversation specific instead of reassuring, and it is public, so both sides can read the same document before the meeting. It is also the reason a security question belongs in procurement rather than in a review after the work is delivered.
What to ask or check
- 01Which release of the list are you working from, and when did you last read it?
- 02Who responds when a vulnerability is found after release, and how quickly?
- 03Can you describe what you do under each of the four practice groups?
What people get wrong
That a supplier can be compliant with it. The document calls itself a standard awareness document representing a broad consensus about risks, and NIST treats it as one of the inputs to a practice framework rather than as a standard to certify against.
Red flags
- A supplier who says they are OWASP compliant.
- A security answer that stops at the code and never reaches the response process.
- A reference to the list with no mention of which release.
Who owns it
OWASP publishes the list and nobody owns your use of it. The practices behind it belong to whoever produces the software, which is the thing to name in an agreement.
Where you will see it
In security questionnaires, in development proposals, and in the security section of a contract somebody copied from a template.