This guide teaches you to use the OWASP Top 10:2025 as a daily working tool, not as a list to tick off during audits. By the end, you will know how to turn the 10 categories into an awareness program for your teams, into actionable code review criteria, and into quality gate requirements built into the CI/CD pipeline. This guide is for beginner developers and DevSecOps engineers who want to structure their security practices around a recognised framework, updated for the first time since 2021.
What you will learn
- Understand the 10 categories of the OWASP Top 10:2025 and what has changed since the 2021 edition
- Use the framework to build a developer awareness program
- Translate each category into concrete, actionable code review criteria
- Define CI/CD quality gates calibrated by severity, without needlessly blocking teams
- Tell apart what automated tools detect from what requires threat modeling
What is the OWASP Top 10?
OWASP (Open Worldwide Application Security Project, "Open Web" until 2023, pronounced "oh-wasp") is a non-profit foundation that documents the most common security risks in web applications. Its Top 10 is the list of the ten most widespread and most exploited categories of vulnerabilities, updated every three to four years.
It is a bit like the annual health checkup of web applications: it does not list every possible disease, but it identifies the ten most frequent causes of application death.
The 2025 edition was presented in November 2025 at OWASP Global AppSec DC, then published in its final version in January 2026: it is the first major update since 2021. Eight categories are now chosen from empirical data drawn from real tests on more than 2.8 million applications and from the analysis of about 220,000 CVEs (identifiers of known vulnerabilities), while the two remaining categories come from a survey of the community of practitioners, to capture risks that automated tools do not yet detect well.
| What the OWASP Top 10 is | What the OWASP Top 10 is not |
|---|---|
| A shared risk framework | A certification standard |
| A vocabulary shared between devs and security | An exhaustive list of all vulnerabilities |
| An awareness and training tool | A checklist sufficient for a full audit |
| A guide to prioritise security efforts | A replacement for threat modeling |
The 10 categories explained simply
Each category of the OWASP Top 10 groups several CWEs (Common Weakness Enumeration, identifiers of software weakness types) under a label understandable by non-specialists. The table below gives, for each one, a one-sentence explanation and a concrete example to anchor the concept.
| # | Category | In one sentence | Concrete example |
|---|---|---|---|
| A01 | Broken Access Control | A user reaches what they should not (now includes SSRF) | Viewing another customer's record by changing an ID in the URL, or forcing the server to query an internal resource through a URL controlled by the attacker |
| A02 | Security Misconfiguration | Default settings leave doors open | Admin interface reachable without authentication |
| A03 | Software Supply Chain Failures | A dependency, a build system or a distribution channel is compromised | An npm dependency replaced by a malicious version |
| A04 | Cryptographic Failures | Sensitive data travels or is stored without protection | Password stored in plain text in the database |
| A05 | Injection | The application executes code supplied by the user | SQL injection: ' OR 1=1 -- that dumps a table |
| A06 | Insecure Design | The feature is badly designed, not just badly coded | A password reset flow that reveals whether an email is registered |
| A07 | Authentication Failures | Authentication or sessions are poorly handled | Session that is not invalidated after logout |
| A08 | Software or Data Integrity Failures | Updates, artifacts or data are not verified | A pipeline that deploys an artifact without checking its signature |
| A09 | Security Logging & Alerting Failures | Security incidents go unnoticed for lack of alerting | 1000 failed login attempts in one minute without triggering an alert |
| A10 | Mishandling of Exceptional Conditions | An error or edge case opens a breach instead of blocking | A payment service that lets the transaction through when validation times out (fail open) |
Prerequisites
This guide focuses on the practical use of the OWASP Top 10, not on explaining HTTP, sessions or DevSecOps concepts from scratch. If these basics are not in place yet, start with the resources below: they set up the common vocabulary the rest of the page relies on.
- Notions of web development (HTTP, sessions, authentication)
- Know the basic concepts of DevSecOps
The DevSecOps introduction gives the vocabulary used here, and threat modeling with STRIDE the method that links each OWASP category to a concrete threat.
How to use the OWASP Top 10 in DevSecOps
The OWASP Top 10 is only useful if you build it into concrete practices. Here are the three most effective uses, from the most educational to the most automated.
Use 1: raising developer awareness
The OWASP Top 10 is an excellent initial training tool. Each category can be the subject of a 45-minute workshop with an exploitable example.
Structure of a workshop per category:
-
Show the vulnerability (10 min): an example of vulnerable code in the team's language. Intentionally vulnerable applications such as OWASP WebGoat exist for this purpose: they let you explore flaws in a safe and legal environment.
-
Exploit it (10 min): show how the attacker exploits the flaw. Nothing sticks in people's minds as much as a real exploitation demo.
-
Fix it (10 min): the secure version of the same code. Explain why the fix works, not only how.
-
Show automated detection (5 min): does a static code analyser (SAST, for Static Application Security Testing) detect this flaw? If so, how to enable the rule. If not, why not.
-
Open discussion (10 min): "Have you ever seen this pattern in our codebase?"
A program of 10 workshops (one per category) represents 7.5 hours of training (10 times 45 minutes) over 10 weeks, a reasonable investment for a team of 5 to 15 developers.
Use 2: structuring code review
The OWASP Top 10 translates into concrete questions to ask when reviewing a pull request:
Questions to ask:
- Does every endpoint check authorisation on the server side (not only on the client side)?
- Are resources accessed by verified ownership, not only by ID?
- Are sensitive endpoints protected by strict roles?
Dangerous pattern, IDOR (Insecure Direct Object Reference):
# ❌ User 42 can access profile 99@app.get("/users/{user_id}/profile")def get_profile(user_id: int): return db.get_user(user_id) # No ownership check
# ✅ Systematic ownership check@app.get("/users/{user_id}/profile")def get_profile(user_id: int, current_user: User = Depends(get_current_user)): if current_user.id != user_id and not current_user.is_admin: raise HTTPException(status_code=403) return db.get_user(user_id)Questions to ask:
- Do SQL queries use bound parameters (never string concatenation)?
- Is user data validated and escaped before being used in queries or in HTML rendering?
- Do dynamically built system commands avoid uncontrolled user input?
Dangerous pattern, SQL injection:
# ❌ SQL injection possiblequery = f"SELECT * FROM users WHERE name = '{user_input}'"db.execute(query)
# ✅ Parameterised query: the input is treated as data, not as codequery = "SELECT * FROM users WHERE name = ?"db.execute(query, (user_input,))Questions to ask:
- Is PII (personally identifiable information) encrypted at rest and in transit?
- Are obsolete algorithms used? (MD5, SHA1, DES and RC4 are considered broken)
- Are keys or secrets present directly in the source code?
- Is TLS (the protocol that secures HTTPS) enforced, even for internal communications?
Questions to ask:
- Does the dependency file (
package.json,requirements.txt,go.mod…) have new entries? - Have these new dependencies been vetted (known vulnerabilities, active maintenance, popularity)?
- Are versions locked to avoid uncontrolled automatic updates?
- Is the build pipeline itself (runners, registries, intermediate artifacts) isolated and audited?
Use 3: defining the quality gates
A quality gate is a blocking condition in the CI/CD pipeline: if the condition is not met, the code cannot be merged or deployed.
Each OWASP category translates into a type of automatable analysis:
| Category | Analysis type | What it looks for |
|---|---|---|
| A01 Access Control | Integration tests | Unauthenticated calls that succeed |
| A02 Misconfiguration | Dynamic analysis (DAST) | Missing security headers, default configs |
| A03 Supply Chain | Composition analysis (SCA) | Dependencies with CVEs above a threshold |
| A04 Crypto Failures | Static analysis (SAST) | Obsolete algorithms in the code |
| A05 Injection | Static analysis (SAST) | String concatenation in queries |
| A09 Logging & Alerting | Static analysis (SAST) | Sensitive data in the logs |
Focus on A06: Insecure Design
A06 is the category hardest to detect automatically. It covers vulnerabilities that come from bad design decisions, not from bugs in the code: the code can be perfectly written and still expose a structural flaw.
Concrete examples:
- A password reset system that says "This email is not registered", which lets the attacker confirm that an account exists
- An API that returns every field of an object while the client only uses two, data overexposure
- A payment flow that checks the amount only on the front end, no server-side validation
- A multi-tenant system that shares resources without strict isolation between customers
No scanner can detect that a feature is inherently badly designed. That is precisely the domain of threat modeling: structured thinking, carried out before writing the first line of code, about the ways an attacker could misuse the intended feature.
The lesson threat modeling with STRIDE shows how to run this design analysis on a real flow, threat by threat, and turn it into requirements that code review can then check.
Focus on A03: Software Supply Chain Failures
A03 is one of the two brand-new categories of the 2025 edition. It groups and extends the old 2021 category on vulnerable components, now covering the whole chain: software dependencies, build systems and distribution infrastructure. This is a supply chain attack (the software supply chain): a malicious dependency injected into a public registry, a compromised build system, or an unverified update.
A notable fact highlighted by the analyses of the 2025 edition: this category shows the fewest occurrences detected in automated tests, but the highest impact and exploitation scores of the whole framework. In other words, these incidents are rare but devastating when they happen.
A few real incidents to illustrate the threat:
- event-stream (npm, 2018): a popular dependency modified to steal cryptocurrency
- SolarWinds (2020): the build system itself compromised to embed a backdoor
- Log4Shell (2021): a ubiquitous logging library with remote code execution
Mitigations rely on generating an SBOM (Software Bill of Materials, an exhaustive list of your software's components, the equivalent of the ingredients on a food label), on artifact signing, and on verifying build provenance.
Not to be confused with: A08 Software or Data Integrity Failures remains a distinct category in 2025, and a narrower one. It covers integrity defects at deployment or execution time (insecure deserialisation, an artifact deployed without signature verification, a pipeline that skips a control step), whereas A03 covers the origin and transport of the components themselves.
The lesson supply chain security details the responses to this category: SBOM, SLSA provenance and artifact signing.
When a vulnerable dependency is discovered, vulnerability management describes the triage, the prioritisation and the closure of the fix.
Common pitfalls
Using the OWASP Top 10 as the equivalent of an audit: the Top 10 covers the most frequent risks, not all risks. A pentest or a full security audit is still necessary.
Assuming that covering the Top 10 is enough: an application can show none of the 10 categories and still have vulnerabilities specific to its business domain.
Leaving security to the security team alone: the OWASP Top 10 is effective precisely because it gives developers a vocabulary and patterns they can spot themselves, without waiting for an external review.
Blocking every finding without distinction: a quality gate that is too strict and generates too many false positives will be bypassed or disabled. Calibrate the thresholds gradually.
Mixing up the 2021 and 2025 numbering: the 2021 A04 Insecure Design has become A06 in 2025, and the former A06 Vulnerable and Outdated Components has been absorbed by the new A03 Software Supply Chain Failures. Always state the edition you cite in your internal documentation to avoid misunderstandings between teams.
Key points
- The OWASP Top 10 is a communication and training tool, not an audit.
- The 2025 edition (final version of January 2026, after a presentation in November 2025) is the first major update since 2021: it introduces two brand-new categories, A03 Software Supply Chain Failures and A10 Mishandling of Exceptional Conditions.
- SSRF, standalone in 2021, is now absorbed into A01 Broken Access Control.
- A02 Security Misconfiguration has climbed from 5th to 2nd place, a strong signal about the risks tied to the cloud and to deployments.
- A06 Insecure Design and A01 Broken Access Control cannot be covered by automated tools alone: they require threat modeling and targeted manual testing.
- OWASP-based quality gates must be calibrated by severity: blocking everything kills team buy-in.
- An awareness program of 10 workshops (one per category) is realistic over 10 weeks and produces measurable results.
Knowledge check
Check that you have the essentials of this guide. The questions cover only what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Automated security testing: SAST, DAST, SCA, fuzzing
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
These short answers cover the questions that come up most often about the OWASP Top 10:2025: what is new compared with 2021, the difference between A03 and A08, and how it compares with an audit. Each one stands on its own.