We closed module 1 with the first risk map of BazarNube: a table of assets (customer data, payments, prices and orders, availability, the legacy Java module) classified with the CIA triad. That map tells us what we are worried about, but still in homegrown language. Now the team needs a shared vocabulary, recognized across the whole industry, to name those threats. That vocabulary exists, and it is probably the most famous security document in the world: the OWASP Top Ten. In this lesson we present it — what it is, how it is built, what it is for and what it is not for — and we go through its current edition (2021), naming its ten categories. We won't exhaust any of them: each has its own development in module 3.

This is the first stop on our "OWASP toolbox" tour. Here we just open the box and describe the tool; the detailed user manual comes later.

1. What the OWASP Top Ten is (and what it isn't)
2. How it is built: data + survey
3. What it is for and what it is NOT for
4. The current edition: Top Ten 2021
5. The ten categories A01–A10
6. What changed from 2017 to 2021
7. The Top Ten applied to BazarNube's risk map

The OWASP Top Ten is an awareness document that gathers the ten most critical security risks for web applications, according to community consensus and the available data. It is published periodically (roughly every 3–4 years) and is, by far, OWASP's best-known flagship project.

The key word is awareness. The Top Ten exists to answer a very concrete question: "If I can only pay attention to a handful of things, where do I start?". It is a starting point, a compass, a lowest common denominator that anyone who develops web software should know.

It is just as important to understand what it is NOT:

• It is NOT an exhaustive standard. It does not list every possible vulnerability; it lists the ten most relevant categories. Meeting the Top Ten does not mean "being secure", it means "having covered the most basic and frequent issues".
• It is NOT a certification checklist. There is no "I comply with the Top Ten" seal. For formal, requirement-by-requirement verification, OWASP has another project: ASVS (lesson 02-02).
• It is NOT a step-by-step remediation manual. It describes the risks and points you in the right direction, but the detail of how to mitigate them relies on other resources (such as the Cheat Sheets, lesson 02-05).

Mental rule: the Top Ten tells you where to look first; it doesn't tell you that you've finished looking.

The Top Ten is not made up in a meeting: it is built with a mixed methodology that combines evidence and expert judgment. Understanding how it is made helps you read it critically.

The two sources are:

1. Data contributed by the community. Companies, consultancies, and tool vendors donate anonymized data about which vulnerabilities they find in real applications. From this come metrics such as incidence (how often a weakness appears) and coverage.
2. Community survey (industry survey). Since historical data only reflects what people already knew to look for, professionals in the field are also asked which risks they consider most important looking forward. This makes it possible to include emerging threats that don't yet appear massively in the data.

In addition, the Top Ten is organized into risk categories, not specific vulnerabilities. For example, "Injection" is a category that groups SQL injection, command injection, LDAP, and so on. This grouping is deliberate: it makes the list stable and understandable rather than an endless list of CVEs.

For the BazarNube team to use the Top Ten wisely, it helps to be crystal clear about its legitimate uses and its common abuses.

The underlying idea: the Top Ten is an excellent beginning and a terrible ending. A classic management mistake is to declare "we've reviewed the Top Ten, we're secure now" and close the matter. The right approach is to use it as an on-ramp toward more complete tools (ASVS to verify, SAMM to mature the program, ZAP to test).

The current edition at the time of this course is the OWASP Top Ten 2021. It introduced several substantive changes compared to the previous one (2017):

• Reordering based on more rigorous data and on the survey.
• Regrouping of categories (some were merged, others expanded).
• A growing focus on design root causes and not just on specific symptoms.

We will work with this 2021 edition throughout the course. It is the reference that module 3 develops category by category.

Here is the full list. We only name them, with a one-line hint of the idea; the real development (examples, vulnerable BazarNube code, mitigations) is the content of module 3.

Two nuances that sometimes cause confusion and are worth fixing now:

• XSS (Cross-Site Scripting) stopped being its own category and became part of A03: Injection. Even so, given its importance, module 3 dedicates a specific lesson to it.
• XXE (XML External Entities) also stopped being its own category and was absorbed into A05: Security Misconfiguration. Module 3 likewise covers it in detail.

Comparing editions helps you understand the evolution of risk. Here is the summary of the most significant changes between 2017 and 2021:

The strategic reading of these changes: web security matured from chasing specific bugs to attacking root causes. The two newcomers — Insecure Design and SSRF — illustrate it: one forces us to think before we code; the other reflects modern architectures (microservices, cloud, internal metadata) where the server itself can be tricked.

Let's return to the risk map that closed module 1. That map spoke in terms of assets and CIA. Now we can translate it into the Top Ten's vocabulary, and thus start populating the findings backlog with recognizable labels:

Lucía (backend lead) proposes something sensible: use the codes A01–A10 as labels in the backlog. That way, when a finding appears, it isn't noted as "weird search bug", but as "A03 – Injection in /api/search". That small gesture connects BazarNube's day-to-day work with a global standard and paves the way for module 3.

Notice that not all the risks fit yet: for example, we haven't labeled anything as A08 or A10 so far. That's normal and healthy: the Top Ten is a guide to where to look, not an obligation to "fill in" all ten boxes.

• Treating the Top Ten as a "pass/fail" checklist. Covering the ten categories does not amount to being secure; it's the minimum. To truly verify, use ASVS (next lesson).
• Confusing categories with vulnerabilities. "Injection" is not a bug, it's a family of bugs. A single finding can touch several categories.
• Using an old edition without realizing it. Much documentation online still cites the Top Ten 2017 (with XSS and XXE as their own categories). Always verify that you're working with 2021.
• Looking here for the "how to fix it". The Top Ten raises awareness; detailed remediation lives in the Cheat Sheets and in module 3. Don't be frustrated if this lesson doesn't give you the exact patch: that's not its purpose.
• Tip: memorize at least A01, A03, and A06 to start with. For a typical e-commerce site like BazarNube, they're the ones you're most likely to encounter in practice.

Exercise 1. Classify each BazarNube situation under the most appropriate Top Ten 2021 category: (a) Marc's frontend displays, without escaping, a product comment that contains <script>; (b) the Dockerfile for the Java module starts in debug mode with the admin console exposed; (c) an attacker tries thousands of passwords against /login with nothing stopping it.

Exercise 2. Explain in 3–5 lines why the Top Ten is not enough as a criterion to tell a client that "BazarNube meets the required security", and which OWASP project would fit that claim better.

Exercise 3. The Top Ten 2021 introduced two new categories compared to 2017. Name them and, for each one, give a plausible example in BazarNube.

Solution 1. (a) A03 Injection (specifically XSS, which in 2021 lives inside Injection); (b) A05 Security Misconfiguration (insecure configuration, exposed administration services — and XXE could also come in here if it processes XML); (c) A07 Identification and Authentication Failures (lack of protection against brute force / credential stuffing).

Solution 2. The Top Ten is an awareness document, not a verification standard: it covers only the ten most frequent categories and doesn't define requirements you can check one by one. Claiming compliance requires a standard of verifiable requirements, and that is OWASP ASVS, which we'll see in lesson 02-02: it lets you say "we have verified the level X requirements" with concrete evidence.

Solution 3. The two newcomers are A04: Insecure Design and A10: SSRF. Examples in BazarNube: (A04) the checkout process was designed without anti-fraud controls or a limit on payment attempts, a design flaw rather than a coding one; (A10) an endpoint that downloads a product image from a URL supplied by the user could be tricked into requesting internal network resources (container metadata, private services).

You have met the first tool in the OWASP box: the Top Ten, an awareness document that lists the ten most critical web risks, built with data + survey and organized into risk categories. You know what it's for (a starting point, common vocabulary, prioritization) and what it's not for (it's not a certification standard or an exhaustive list). You have gone through the 2021 edition with its categories A01–A10, understood the mergers (XSS→A03, XXE→A05) and the newcomers (Insecure Design and SSRF), and you have started labeling BazarNube's backlog with this vocabulary.

But the Top Ten itself has left us with an open question: if it raises awareness but doesn't verify, how do we prove, requirement by requirement, that BazarNube is secure? That is exactly the job of the next tool. In lesson 02-02 we present OWASP ASVS, the standard that turns "being aware" into "being able to verify it".