Before you write a single line of secure code, it helps to know who can help you get it right. In the world of web application security, that "who" has a name that comes up again and again: OWASP. In this lesson you will understand what OWASP is, what problem it solves, what kinds of resources it puts at your disposal, and how it organizes its work. All of this is the foundation on which the rest of the course is built, so it is worth setting it down firmly.

So that it doesn't remain abstract theory, we will also introduce BazarNube, the fictional marketplace that will accompany us throughout the course, and we will see why its development team decides to start looking toward OWASP.

Contents

  1. What OWASP is (definition and legal nature)
  2. What problem OWASP solves
  3. The kinds of resources OWASP offers
  4. The project-based working model (flagship, production, lab)
  5. Local chapters and the community
  6. Case study: BazarNube discovers OWASP

  1. What OWASP Is

OWASP stands for Open Worldwide Application Security Project (formerly Open Web Application Security Project). It is an open, non-profit community dedicated to improving software security, with a historical focus on web applications.

Let's break down the three key ideas in that definition:

  • Open community: anyone can take part, propose, review, and use its materials. There is no fee to pay and no need to belong to a particular company. Most of its content is published under free licenses (such as Creative Commons), which lets you copy, adapt, and distribute it.
  • Non-profit: OWASP is backed by a foundation registered as a 501(c)(3) organization in the United States (and there is also a foundation in Europe). That legal status corresponds to tax-exempt charitable and educational entities; in practice it means OWASP does not sell a product or work to maximize profit, but to fulfill a public-interest mission.
  • Vendor neutrality (vendor-neutral): OWASP does not sell commercial tools or recommend one vendor over another. This is fundamental to its credibility: when OWASP says something is a risk, there is no commercial interest behind it.

A note on the acronym. You will sometimes see OWASP written as "Open Web..." and other times as "Open Worldwide...". In 2023 the organization updated its name to reflect that software security goes beyond the web (APIs, mobile, containers, and so on), but the acronym and the mission did not change.

  1. What Problem OWASP Solves

Imagine you are a developer and you are asked to make an application "secure". Secure against what? How do you know when you have achieved it? What do you compare it against? This is where the problem OWASP helps solve comes in.

Software security has historically suffered from three shortcomings:

Problem Description How OWASP addresses it
Lack of common knowledge Every team reinvents what "secure" means and makes the same mistakes others have already made. It documents risks and best practices publicly and by consensus.
Lack of a shared language Developers, auditors, and managers use different terms and talk past each other. It offers taxonomies and standards (such as the Top Ten or ASVS) that serve as a common vocabulary.
Lack of accessible tools Security tools used to be expensive or closed. It publishes free, open tools to test and protect applications.

In one sentence: OWASP turns the scattered knowledge of thousands of professionals into open, reusable, comparable resources, so that each team doesn't have to learn security by suffering its own incidents.

  1. The Kinds of Resources OWASP Offers

OWASP is not a single thing; it is an umbrella under which many resources of very different natures coexist. It helps to classify them so you don't get lost. In module 2 we will get into the detail of the specific projects; here we just want you to recognize the categories.

  • Documentation and guides: texts that describe risks and best practices. The most famous example is the OWASP Top Ten, a list of the ten most critical risks in web applications. This category also includes the Cheat Sheets (practical fact sheets) and testing guides.
  • Standards: documents that define verifiable requirements. The best known is ASVS (Application Security Verification Standard), which we will see in module 4. A standard lets you answer "yes/no" to "does the application meet this requirement?".
  • Software tools: programs to find or mitigate vulnerabilities. The best known is ZAP (an interception proxy for testing applications), covered in module 6.
  • Maturity models and frameworks: such as SAMM (module 5), which helps an organization assess and improve how it does security over time.
  • Local chapters and events: the human, in-person side of the community, which we will see in section 5.

The following diagram summarizes the ecosystem. Notice that everything hangs from the OWASP Foundation, but each branch serves a different purpose:

graph TD
    A[OWASP Foundation<br/>non-profit] --> B[Documentation and guides<br/>e.g. Top Ten, Cheat Sheets]
    A --> C[Standards<br/>e.g. ASVS]
    A --> D[Tools<br/>e.g. ZAP]
    A --> E[Maturity models<br/>e.g. SAMM]
    A --> F[Local chapters<br/>and AppSec events]

The idea to hold on to: when someone says "use OWASP", you have to ask "which OWASP resource?", because a guide, a standard, and a tool are used in very different ways.

  1. The Project-Based Working Model

All of OWASP's material is organized into projects. A project is a specific initiative with its own leads, its own repository, and its own documentation (for example, "OWASP Top Ten" is one project, and "OWASP ZAP" is another).

To guide users on how much they can rely on each project, OWASP classifies them by maturity level. Although the exact labels have evolved over time, the classic model distinguishes three levels:

Level What it means How to use it
Flagship Strategic projects that are mature, widely adopted, and actively supported by the community. You can rely on them with confidence in production.
Production Stable and useful projects with a solid user base, though not as central as flagship ones. Suitable for real use, checking their recent activity.
Lab / Incubator Young or experimental projects, still in development. Useful to explore, but with caution: they may change or be abandoned.

This classification is a very practical compass. When you assess whether to adopt an OWASP resource, looking at its maturity level tells you at a glance whether it is a safe bet (flagship) or something still green (lab).

Tip. Projects such as the Top Ten, ASVS, ZAP, and SAMM — the ones we will study in this course — are flagship. That is no coincidence: they are the ones the industry uses massively.

  1. Local Chapters and the Community

Beyond documentation, OWASP is also people. It is organized into local chapters: groups by city or region (for example, a Barcelona chapter, a Madrid chapter, and so on) that hold talks and meetups, usually free and open.

In addition, OWASP runs global conferences known as AppSec (for Application Security), where professionals from all over the world share research and experience. We will dig deeper into chapters and events in lesson 01-02.

The underlying idea is that OWASP works thanks to volunteers: people who devote their time to writing guides, maintaining tools, and energizing the community. That is why its value is not only the material you download, but the network of professionals behind it.

  1. Case Study: BazarNube Discovers OWASP

Let's ground everything above in the case that will accompany us throughout the course.

BazarNube is a startup that has launched an e-commerce marketplace: an online store where multiple sellers list products and customers buy and pay. Its architecture, very typical of a modern startup, is as follows:

graph LR
    U[Customer<br/>browser] --> F[React frontend<br/>SPA]
    F --> API[Backend API<br/>Node.js + Express]
    API --> DB[(PostgreSQL)]
    API --> LEG[Legacy module<br/>billing/orders<br/>Java + Spring Boot]
    LEG --> DB
  • Frontend: a single-page application (SPA) built in React.
  • Backend: a Node.js + Express API.
  • Legacy module: billing and orders still run on an old Java + Spring Boot component inherited from the first version.
  • Database: PostgreSQL.
  • Deployment: everything in Docker containers in the cloud.

The team is small: Lucía (backend lead), Marc (frontend), and an SRE who manages the infrastructure. You join as an AppSec engineer (application security).

What happened for them to hire you? During a funding round, a potential client asked: "How do you protect your users' payment data?" No one could give a structured answer. Lucía suggested "doing security right", but they ran straight into the three shortcomings we saw in section 2: they had no common knowledge, no shared language, and no tools.

Looking for solutions, the team found OWASP and realized it solved exactly that:

  • They could start with a guide to risks (the Top Ten) to know "what to protect against".
  • They could adopt a standard (ASVS) to have concrete requirements to verify.
  • They could use a tool (ZAP) to test the application without paying for licenses.
  • And all of it with the peace of mind that these are flagship projects: mature and neutral.

Throughout the course, you will help BazarNube build a security findings backlog and a threat model. But the first step is the one you have just taken: knowing what OWASP is and what it offers you.

Common Mistakes and Tips

  • Believing that "OWASP" is a single thing. OWASP is an umbrella of many projects. Saying "apply OWASP" without specifying the resource is as vague as saying "use the internet". Always be specific: the Top Ten? ASVS? ZAP?
  • Confusing the Top Ten with "all of OWASP". The Top Ten is its most famous resource, but it is only an awareness list. Reducing OWASP to the Top Ten leaves out far more powerful standards and tools.
  • Ignoring a project's maturity level. Not all OWASP projects have the same backing. Before adopting one, check whether it is flagship, production, or lab.
  • Thinking that OWASP certifies products. OWASP is neutral and does not endorse commercial tools. If a product claims to be "OWASP-certified", be suspicious: OWASP does not grant commercial seals.
  • Tip: bookmark the official site (owasp.org) and the Top Ten project. They will be your constant entry point.

Exercises

Exercise 1. Classify each of the following OWASP resources by its type (documentation/guide, standard, tool, or maturity model): (a) OWASP Top Ten, (b) OWASP ASVS, (c) OWASP ZAP, (d) OWASP SAMM.

Exercise 2. The BazarNube team finds two OWASP projects that would suit them. Project A is labeled flagship and project B is labeled lab/incubator. They are going to use one in their production pipeline right away. Which would you choose as the main foundation, and why? What precaution would you take with the other?

Exercise 3. Explain in your own words, in 3-4 lines, why OWASP's vendor neutrality and its non-profit (501c3) nature increase the trust you can place in its recommendations.

Solutions

Solution 1.

  • (a) OWASP Top Ten → documentation/guide (a risk awareness list).
  • (b) OWASP ASVS → standard (verifiable requirements).
  • (c) OWASP ZAP → tool (security testing software).
  • (d) OWASP SAMM → maturity model (a framework to assess and improve an organization's security).

Solution 2. I would choose project A (flagship) as the main foundation, because it is mature, widely adopted, and actively supported by the community, which reduces the risk of it being abandoned or changing disruptively just when you depend on it in production. With project B (lab), caution is warranted: I could explore it and run tests, but I would not make it a critical piece in production until it matures, and I would keep an eye on its activity.

Solution 3. Being vendor-neutral, OWASP does not make money by recommending a specific tool, so its advice is not biased by a commercial interest. Being a non-profit (501c3) entity, its stated goal is the public interest (educating and improving security), not selling. Both facts make its recommendations more credible and independent than those of a vendor that wants to sell you its product.

Conclusion

In this lesson you have learned that OWASP is an open, non-profit community (a 501c3 foundation) that solves a very real problem: the lack of common knowledge, shared language, and accessible tools in software security. You have seen that it offers five kinds of resources — documentation, standards, tools, maturity models, and community — that it organizes its work into projects classified by maturity (flagship, production, lab), and that its value rests on thousands of volunteers and local chapters. And you have met BazarNube, the startup whose team (Lucía, Marc, and the SRE, with you as the AppSec engineer) begins this journey.

In the next lesson, 01-02 History and Mission of OWASP, we will go back to 2001 to understand where this organization comes from, what its mission is — "make software security visible" — and how its principles of openness and neutrality fit a startup like BazarNube.

OWASP Course: Guidelines and Standards for Web Application Security

Module 1: Introduction to OWASP

Module 2: Main OWASP Projects

Module 3: OWASP Top Ten 2021 in Depth

Module 4: OWASP ASVS (Application Security Verification Standard)

Module 5: OWASP SAMM (Software Assurance Maturity Model)

Module 6: OWASP ZAP (Zed Attack Proxy)

Module 7: Best Practices and Recommendations

Module 8: Practical Exercises and Case Studies

Module 9: Assessment and Certification

© Copyright 2026. All rights reserved