OWASP, the open
application-security toolkit

OWASP stands for the Open Worldwide Application Security Project. It is a nonprofit foundation that produces free, community-driven resources to help teams build and verify secure software. It is not a certification, a law, or a single framework — it is a body of standards, guidance and tools that engineering and application-security teams adopt and align to.

That distinction matters, because OWASP is often spoken of as if it were a badge to earn. There is no "OWASP certificate" and no auditor who certifies you against OWASP. Instead, teams say their software is "tested against the OWASP Top 10" or "built to meet the ASVS at level 2" — they are aligning to a published standard, not passing an exam.

OWASP is best understood as a toolbox. Some projects raise awareness of the risks that matter most; one is a detailed, verifiable requirements standard; another is a model for maturing how your team builds software. You pick the parts that fit the software you ship.

The OWASP Top 10 is the project most people mean when they say "OWASP". It is an awareness document that lists the most critical security risks to web applications — categories such as broken access control, injection, security misconfiguration and vulnerable components, ranked by how common and how serious they are across the industry.

It is updated periodically as the threat landscape shifts; the widely-referenced edition is the 2021 list, with a new edition in progress. Each entry is a category of risk rather than a single bug, which is why it works as an awareness and prioritization tool: it tells a team where the most damage tends to come from, so they know where to focus first.

The important thing to understand is what the Top 10 is not. It is not a checklist you certify against, and "covering the Top 10" does not mean an application is secure. It is the starting point, the risks no team should be blind to, not the finish line. For a verifiable standard you can build and test against, OWASP points you to the ASVS.

The OWASP Application Security Verification Standard (ASVS) is where awareness becomes something you can verify. Where the Top 10 names the risks, the ASVS is a structured framework of detailed security requirements — for authentication, session management, access control, input validation, cryptography and more, that teams design, build and test their applications against.

The requirements are organized into levels of increasing assurance. Level 1 (L1) is a baseline appropriate for most applications and is largely testable from the outside; Level 2 (L2) is the standard most applications handling sensitive data should aim for; Level 3 (L3) adds the rigour expected of the most critical software. Choosing a level sets the bar your application is verified against.

In practice the ASVS is the answer when someone asks for evidence rather than intent. It turns "we follow OWASP" into a concrete set of requirements you can map your controls and test results to — which is exactly the kind of thing an auditor or a security-conscious customer wants to see.

OWASP SAMM (the Software Assurance Maturity Model) shifts the question from "is this application secure?" to "is our way of building software secure?". It is a model for assessing and improving the maturity of your secure software development lifecycle (secure SDLC) — the practices around governance, design, implementation, verification and operations.

SAMM lets a team measure where its application-security practices stand today, set a realistic target, and plan the steps to get there. It is most useful for organizations that have moved past one-off fixes and want a program: a deliberate, improving way of building software securely rather than a scramble before each release or audit.

SAMM and the ASVS complement each other. The ASVS verifies a given application against requirements; SAMM matures the organization that builds applications. Teams often use the ASVS to raise the bar on what they ship and SAMM to raise the bar on how they ship it.

Web applications are not the only thing teams ship, so OWASP maintains focused projects for other surfaces. The OWASP API Security Top 10 mirrors the flagship list but for APIs, covering the risks specific to them — broken object-level authorization, broken authentication, and the other failures that show up when machines, not browsers, are the clients.

For mobile, the OWASP MASVS (Mobile Application Security Verification Standard) plays the role the ASVS plays for web: a structured set of verifiable security requirements for mobile apps. If your product is an API platform or a mobile application, these are the OWASP projects that map most directly to what you build.

OWASP also publishes a wide library of supporting material — the Cheat Sheet Series of concise implementation guidance, and tools such as ZAP for security testing and Dependency-Check for finding known-vulnerable components. They are not standards to align to so much as practical help in meeting the ones you have chosen.

OWASP is rarely the end goal in itself. More often it is how teams operationalize the "secure development" expectations that other frameworks require but do not spell out. Those frameworks ask you to develop software securely; OWASP is the concrete answer to how.

ISO 27001 includes a secure-development control in Annex A; aligning your development to OWASP, testing against the Top 10 and building to the ASVS, is a practical way to demonstrate it. PCI DSS references secure coding practices, and the OWASP Top 10 is the reference those practices are commonly anchored to. SOC 2 looks at your change and development controls, where an OWASP-aligned secure SDLC gives you something concrete to point to.

So when one of those frameworks asks how you build software securely, "we align our SDLC to OWASP" is often the practical, evidence-backed answer. The work you do to align to OWASP is the same work those controls are asking for — done once and reused across them.

OWASP is used primarily by the people who build and secure software: engineering teams, application-security and product-security specialists, and the architects who set development standards. It is vendor-neutral and free, which is why it has become the default reference rather than any single vendor’s methodology.

How a team uses it depends on maturity. A team early in its journey might start by making sure it is not exposed to the OWASP Top 10 risks. A more established team designs and tests against the ASVS at a chosen level, and uses SAMM to keep improving how it builds. The resources scale from a first awareness pass to a measured, continuously improving program.

Because there is nothing to certify against, adopting OWASP means choosing how you will measure yourself and then doing it consistently. The common approach is to use the Top 10 to set awareness and priorities, the ASVS at a chosen level as the requirements you verify against, and SAMM to track the maturity of the program over time.

The practical challenge is keeping all of that current and connected. OWASP alignment is not a one-time pass: requirements change as the standards are revised, new code introduces new risk, and the evidence that you actually meet a requirement has to be maintained, not just produced once. Teams that keep their OWASP mapping in scattered spreadsheets find it stale the moment a customer or auditor asks to see it.

The goal is a living picture: which ASVS requirements apply, where each one stands, what proves it, and how that maps to the compliance controls it also satisfies — kept current as the software and the standards both move.