What OWASP is, and which of its projects a small team actually uses

The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation whose volunteers publish free, vendor-neutral guidance on building and testing secure software. It is not a law, a certificate or a product. It runs more than 275 active projects, and a small team needs 4: the Top 10, ASVS, the Cheat Sheet Series and the Web Security Testing Guide.

What OWASP is: the Open Worldwide Application Security Project in plain words

OWASP, the Open Worldwide Application Security Project, is a nonprofit foundation launched in 2001 that publishes free application security lists, standards, guides and tools, most of them written by volunteers. It certifies no vendor or software, so OWASP compliant on a product page only ever means someone checked against one of its documents.

The foundation also runs more than 250 local chapters. OWASP’s About page describes the community as “respectful, supportive, truthful, and vendor neutral.” Older reports spell the name out as the Open Web Application Security Project, which is what the letters meant until 2023. Where its documents sit among the other controls a live app needs is the subject of my guide to web app security.

What the foundation publishes falls into six kinds of thing, and knowing the kind tells you how to use it:

Every OWASP project carries a level, and the level tells you how much weight a citation deserves. OWASP’s project list sorts an inventory of 324 entries into four tiers: flagship projects “have demonstrated strategic value to OWASP and application security as a whole”, production projects are “production-ready”, lab projects are “experimental and emerging”, and incubator projects are “early-stage and community-driven initiatives”. A flagship standard and an incubator draft carry the same name on the cover, so the tier is the first thing to look up when a vendor leans on one.

OWASP writes documents and tools; it does not hand out a compliance status. Its own verification standard states that “OWASP, as a vendor-neutral nonprofit, does not certify any vendors, verifiers, or software”, and that any certification “claiming ASVS compliance is not officially endorsed by OWASP.” The one certification in sight is for people: in October 2025 the foundation announced it is “currently working on a new initiative to create a certification program for developers.” So OWASP certified on a product page is the vendor’s own claim, and the useful reply is three questions, my reading of what makes the claim checkable: which list, which version, and where are the results.

OWASP’s meaning in cyber security is exactly that narrow, and in 2026 the word on a questionnaire, in my reading, most often stands for the current Top 10 edition, covered in its own section below.

What does OWASP stand for? Open Web, then Open Worldwide

OWASP stands for Open Worldwide Application Security Project. Until 2023 the W stood for Web, which is why both full forms are still searched and printed on older reports and course pages. The letters stayed the same through the rename; only the word behind the W changed.

The change was a board decision, not a rebrand of the projects. At its meeting in Dublin on 15 February 2023, the OWASP board passed, 6-0, a motion to “change all current and future references” of the Open Web name to the Open Worldwide one. So the full form of OWASP on anything printed before that date, from a course slide to a penetration test report, reads Web, and it names the same organization.

Why it matters for a small SaaS: the four places the word turns up

The word rarely arrives on its own. For a small SaaS team it tends to show up in one of four places, and each hides a more specific question than the acronym suggests. This table is my reading of those four places:

In all four, what OWASP is used for in practice is a shared vocabulary for one question: whether anyone has looked for the common classes of flaw and can show the work. A bare “yes” answers none of them. The category-by-category picture for AI-built apps is in where AI-built apps land on the OWASP Top 10, and the honest answer to a questionnaire row is a dated result per category, which how to test OWASP Top 10 vulnerabilities shows how to produce.

The foundation itself is a useful reminder that these classes are ordinary. In late February 2024, after a few support requests, OWASP became aware of a misconfiguration of its old wiki web server that had exposed member resumes more than a decade old; it advised anyone who was a member from 2006 to around 2014 and provided a resume when joining to assume theirs was part of the leak. Its notice of 29 March 2024 says it disabled directory browsing, reviewed the web server and MediaWiki configuration, removed the resumes and purged its Cloudflare cache; a revision on 19 April 2024 calls it a leak rather than a breach, because the files were exposed “due to a misconfiguration, not because of an attack,” and OWASP does not know whether anyone accessed them. The lesson I take from it: I’d file it under A02:2025 Security Misconfiguration, and if the people who write the list can run a misconfigured server, the list is a prompt to look at your own app, never a badge to claim.

How it works: the projects a small team actually uses

A small team needs, by my working rule, 4 OWASP documents and 3 kinds of tool: the Top 10 to read once, ASVS to build against, the Cheat Sheet Series when writing a feature and the Web Security Testing Guide when testing; then a dependency checker in CI, a dynamic scanner before launch, and Juice Shop for practice.

The shortlist below takes the kind of each project from its own page. The last two columns are my working rule, sized for a team of one or two developers, and the times are rough.

What a small team can leave for now: SAMM, which measures a whole organization’s security practice; the long tail of lab and incubator projects; and chapter events, which are good for learning but do not change the app.

The OWASP Top 10: what the list is, the editions from 2003 to 2025, and the spin-off lists

The OWASP Top 10 is, in its project’s words, a standard awareness document on the most critical security risks to web applications. Web editions came out in 2003, 2004, 2007, 2010, 2013, 2017, 2021 and 2025. Searches for 2016, 2018 or 2019 land on the mobile, 2017 or API lists.

It names classes of risk and ranks them; it gives you nothing to tick off, which is the job ASVS does. For 2025 the team ranked the categories from contributed data covering over 2.8 million applications, then took two of the ten from a community survey, because in the team’s words, examining the contributed data “is essentially looking into the past.” The OWASP Top Ten project counts the 2025 list as its “8th installment”, which matches the eight years in the editions table.

The latest OWASP Top 10 is the 2025 edition; the OWASP Top 10 project calls it “the most current released version”, and neither its pages nor the repository README print a release date for the OWASP Top 10 2025. In 2026 the OWASP Top 10 to read is still that 2025 list, since no newer web edition has replaced it on the project page. These are the ten categories, named only; testing each one belongs to the guide linked in the section above.

The 2025 list names categories of OWASP Top 10 vulnerabilities, each a group of related weaknesses, rather than single bugs. The editions table below is the edition map: every web edition in the Top 10 repository, with every edition, what it ranked first, and what the repository or the edition itself says about it.

The OWASP Top 10 is not updated every year: the gaps between web editions run from one year, 2003 to 2004, to four, 2017 to 2021 and 2021 to 2025. The OWASP Top 10 2004 and 2007 editions, like the 2010 one, are kept as folders in the Top 10 repository. The OWASP Top 10 2017 vs 2013 change came through three additions, XML External Entity (XXE), Insecure Deserialization and Insufficient Logging & Monitoring, while Cross Site Request Forgery and Unvalidated Redirects and Forwards dropped off the ranked list. The 2017 top ten that OWASP put out were ten risks rather than principles, with Injection first.

Old reports and courses still cite 2017 codes, and 2021 renamed several of them: A3:2017-Sensitive Data Exposure became A02:2021-Cryptographic Failures, Broken Authentication became Identification and Authentication Failures, and Insecure Design, Software and Data Integrity Failures and Server-Side Request Forgery arrived as new categories. The OWASP Top 10 2021 list was replaced in 2025 by one that adds Software Supply Chain Failures, an expansion of the 2021 vulnerable-components category, and Mishandling of Exceptional Conditions, and that rolls Server-Side Request Forgery into Broken Access Control. Link the project page when you cite an edition, never a year-specific URL: project pages have moved before, and a code like A3:2017 only makes sense next to its year.

Searches for OWASP Top 10 vulnerabilities by year run into gaps: 2016 and 2024 are mobile-list years, 2019 and 2023 are API-list years, and a web search for 2018, 2020, 2023 or 2024 lands on the 2017 or 2021 edition, whichever was current then.

Beside the web list sit the spin-offs, each a separate OWASP project with its own editions and its own level. The last column is my reading: a spin-off matters only to a team that runs that thing itself, and an app on Vercel and Supabase does not run Kubernetes.

The OWASP API Security Top 10 has two editions, 2019 and 2023, so a search for a 2024, 2025 or 2026 API list lands on the 2023 one; how an app’s own checks line up with it is in an API security assessment against the OWASP API Top 10. In the OWASP Mobile Top 10, insufficient cryptography was M5 in 2016 and is M10 in 2024; the rest of the mobile list, and the standard behind it, is in mobile app security best practices. The AI lists have moved fastest: the current edition and every risk in it are in the OWASP LLM Top 10, and the top risk on that list gets its own explainer, what is prompt injection.

The OWASP Top 10 for Kubernetes shows how uneven the spin-offs are: the project’s own site says “2025 Top 10 Risks now available Feedback welcome”, while its summary on owasp.org still says the 2025 update is in progress, so read the Kubernetes Top 10 project directly. For container security, OWASP’s Docker Top 10 is a list of controls rather than risks: its page says its ten points “represent security controls.” The OWASP Serverless Top 10 is so far an interpretation of the web list; its page says an open call for data will come first, then the official Serverless Top 10 report. For cloud security, the OWASP list is the Cloud-Native Application Security Top 10, and its page still shows an interim list, last updated in April 2022. The OWASP Machine Learning Security Top 10, or ML Top 10, is a lab project whose page says the current version “is in draft and is being modified frequently.” The OWASP Top 10 for thick clients is the Desktop App Security Top 10, a 2021 list that asks companies to make sure their “desktop applications / thick-clients minimize these risks.”

OWASP ASVS: the application security verification standard, and how it differs from the Top 10

OWASP ASVS, the Application Security Verification Standard, is a list of testable security requirements, around 350 of them in 17 chapters, with three levels of rigor. The Top 10 says what goes wrong most and ASVS says what must be true, so a team reads the first once and builds, reviews and contracts against Level 1 of the second.

Each ASVS requirement is written so that checking it “must result in a ‘fail’ or ‘pass’ decision”, which is what makes it usable in a contract or a review. The ASVS project offers version 5.0.0 as the latest stable release, and 5.0 is a real break from 4.0: of the 286 requirements in version 4.0.3, only 11 remain unchanged, and new chapters cover OAuth and OIDC, WebRTC and self-contained tokens. Searches still ask about ASVS 4.0, and the purpose OWASP states for ASVS on its project page covers every version: to “normalize the range in the coverage and level of rigor available in the market” for web application security verification.

OWASP’s security standards for verifying apps are ASVS for web applications and MASVS for mobile apps; the Top 10, by its own description, is an awareness document. Ask a search engine for a web application security standard and its AI answer names ASVS as the benchmark. I agree, for a plain reason: it is free and written for applications, while the ISO and NIST documents most often named beside it are management-system and control-catalog standards. For a web app, ASVS is the security standard I’d point a team to first.

Here is the OWASP Top 10 vs ASVS, side by side:

ASVS says Level 1 “contains the minimum requirements to consider when securing an application”, around 20% of its requirements, and gives the example that “an early-stage startup that is only collecting limited sensitive data may decide to focus on Level 1”. My working rule for a two-person team: take Level 1, strike what does not apply with a written reason, and work the rest as a checklist. How ASVS differs from SAMM is answered in the questions at the end.

OWASP testing: the Web Security Testing Guide and the Cheat Sheet Series

The OWASP Web Security Testing Guide is the manual testers follow, with an id for every test case, and its checklist sits in a folder of the project’s GitHub repository. The Cheat Sheet Series is the builder’s side: one short page per topic, from password storage to file upload.

The Web Security Testing Guide is at version 4.2 as its stable release, with 5.0 in development. Its testing chapter runs through 12 categories, from information gathering, configuration, identity, authentication, authorization and session management to input validation, error handling, weak cryptography, business logic, client-side testing and API testing. Each test has an id such as WSTG-INFO-02, and the project describes the guide as “a framework of best practices used by penetration testers and organizations all over the world”, so a tester’s report may use its ids and follow its structure. The checklist itself sits in the repository’s checklists folder, and a separate guide on the WSTG checklist covers how to use it. What a full test involves, and how a small one is agreed, is in web application penetration testing.

The OWASP Cheat Sheet Series is the fastest OWASP resource to act on, in my reading: its project page counts 121 published sheets, and the index has one each for authentication, authorization, session management, password storage, file upload, HTTP headers and logging. The repository keeps indexes that map sheets to ASVS, MASVS and the Top 10, so a failed ASVS requirement can lead you to the sheet on the same topic.

OWASP tools: scanners, dependency checks and what a scan can tell you

OWASP tools cover dependency checks, attack-detection rules, bill-of-materials files and practice apps, but no scanner covers the whole Top 10. A crawler signed in as one user cannot ask whether that user can read another customer’s data, which is the category the current list ranks first.

There is a free scanner available, but it is no longer OWASP’s: ZAP, the open source tool usually meant by an OWASP Top 10 scanner, has not been an OWASP project since September 2023, when its team “had to take ZAP out of OWASP” to fund its work, and it is now known as ZAP by Checkmarx. A scan like ZAP’s crawls a running app and probes what it can reach from the outside. No OWASP Top 10 scanning tools replace a person checking whether one account can see another’s records, so run a scanner only against systems you own or are authorized to test, and treat its report as one input.

The OWASP tools list worth knowing is short. The first two columns come from each project’s page; the last column is my reading of each tool’s blind spot:

What a scanner proves about an AI-built app, and what it cannot, is covered with figures in the audit guide linked in the section on why the word matters.

The TryHackMe rooms: “Application design flaws” and “Insecure data handling”

These two phrases are not OWASP category names. They are titles of TryHackMe training rooms, easy ones of about 30 minutes each, that group 2025 categories into themes. The TryHackMe room OWASP Top 10 2025: Application Design Flaws describes itself as covering A02, A03, A06 and A10, though its first task lists A02, A03, A04 and A06, so check the room itself before you rely on either. The OWASP Top 10 2025: Insecure Data Handling room covers A04 Cryptographic Failures, A05 Injection and A08 Software or Data Integrity Failures. I give no answers here: the rooms are graded exercises, and doing them is the point. For a founder, the cheaper first hour is reading the ten category pages with your own stack in mind.

How to check your own app: one afternoon with three of the projects

An OWASP pass on a small app is, by my working rule, 5 checks in one afternoon: place each of the ten categories in your app, mark ASVS Level 1 authentication and authorization, try to read another account’s record, triage the dependency scan, and compare one feature with its cheat sheet.

Run every check against your own deployed app, or a staging copy with the same sign-in and data rules, using test accounts only. Each one can fail, and each leaves a piece of evidence to keep:

1. 01 Open the current Top 10 and write one sentence per category on where that class could occur in your app, or "not applicable, because" and the reason. It fails if you cannot place a category. Keep the dated ten-line table.
2. 02 Take the Authentication (V6) and Authorization (V8) chapters of ASVS 5.0.0 and mark each Level 1 requirement met, not met or not applicable. Keep the marked list with the ASVS version on it.
3. 03 With two test accounts, change the record id in a request made as account A to one owned by account B. It fails if B's data comes back; it passes if the app refuses, returns not found, or returns an empty result because row-level security filtered the query. Keep the request and the response.
4. 04 Run the dependency scanner your platform already has and list only the findings in code paths the app actually calls. Keep the report and your triage note.
5. 05 Open the cheat sheet for one thing you built this month, such as file upload or sessions, and compare it line by line with your code. Keep the diff or the ticket it produced.

Check 3 is the first-ranked category, and a scan signed in as one user does not run it. This is also how the sprint’s OWASP Top 10 review, deliverable 3.7, is verified: “Deliver category-level results and supporting test evidence, with justified non-applicable cases identified.”

Where the sprint fits

Two deliverables in the Production Hardening Sprint sit closest to this page. In OWASP Top 10 review (3.7), we review the application against the OWASP Top 10 and record findings, fixes, and evidence by category; in Targeted external penetration testing (3.10), we test the five highest-risk externally reachable attack surfaces, remediate findings, and deliver the methods and evidence. The targeted security tests cover the five priority attack surfaces documented in the report, and the package also includes an OWASP review and a controls checklist with evidence; formal third-party certifications and independent audit opinions are separate from the sprint deliverables. Both are listed, with the rest, in the published scope.

Common questions about the foundation and its projects

Is OWASP free?

Yes. OWASP says “all of our projects, tools, documents, forums, and chapters are free and open to anyone interested in improving application security.” Each project names its own license: ASVS uses Creative Commons Attribution Share Alike 4.0, the 2025 Top 10 uses Creative Commons Attribution 3.0, and the Kubernetes Top 10 uses CC BY-NC-SA 4.0, so check the license before you copy text into a product.

Who is behind OWASP?

The OWASP Foundation, Inc., a United States 501(c)(3) nonprofit incorporated on April 21, 2004, after the project itself launched on December 1, 2001. It has had an elected board since 2011, and each project is run by named volunteer leaders listed on its page.

Is OWASP a credible source?

Yes for its flagship documents; in my reading they are what testers, standards and questionnaires cite by name, and the caveats are the level and the date. Flagship is the top of OWASP’s four project tiers, while an incubator project is early-stage work. Some lists, like the Machine Learning Security Top 10, say plainly that they are drafts, so check the tier and the edition year before you quote one.

What is the difference between OWASP ASVS and SAMM?

ASVS verifies an application; SAMM measures an organization. ASVS “provides a basis for testing web application technical security controls”, while SAMM, the Software Assurance Maturity Model, is “an effective and measurable way for any organization to analyze and improve their security posture.” A two-person team gets more from ASVS first, in my reading; SAMM earns its place once there is a security program to measure.

How to learn OWASP Top 10?

Read the ten category pages of the 2025 edition, write one line per category on where it could occur in your own app, then practice on a deliberately vulnerable app. Juice Shop “encompasses vulnerabilities from the entire OWASP Top Ten”, and the TryHackMe rooms above work the same way. That order, reading then placing then breaking, is my working rule for a builder rather than a security specialist.