Introduction

ntroduction

The OWASP Top 10 is one of the most widely used references for understanding critical web application security risks. It is not a complete testing methodology, legal compliance standard, or exhaustive security checklist. Used correctly, it gives developers, security teams, and managers a shared risk language: it helps explain not only the technical name of a weakness, but also its root cause and how it should be prioritized.

What Is OWASP?

OWASP, the Open Worldwide Application Security Project, is an open, community-driven security ecosystem focused on improving software security. The OWASP Foundation produces free documentation, standards, tools, and educational resources through contributions from developers, security researchers, auditors, trainers, and organizations. Its broader mission is to make application security more visible, understandable, and practical.

The OWASP name was known for a long time as the Open Web Application Security Project. That name reflected the project’s early focus on web application security. Over time, the OWASP ecosystem expanded beyond classic web applications to include APIs, mobile applications, software supply chain security, cloud-native systems, LLM applications, and broader application security practices. The current official name is therefore Open Worldwide Application Security Project. Even so, the OWASP Top 10 project covered in this training remains a dedicated list focused on web application security risks.

OWASP is not only the Top 10 list. As shown on the official OWASP Projects page, the ecosystem includes many projects at different maturity levels. OWASP ASVS provides verifiable security requirements for modern web applications and services; OWASP SAMM helps organizations measure software security maturity; and OWASP Cheat Sheet Series gives practical secure coding guidance for developers and defenders.

Open-source tools are also an important part of the OWASP ecosystem:

• OWASP ZAP: Used for proxy-based dynamic security testing of web applications.
• OWASP Dependency-Check: Helps identify components with known vulnerabilities.
• OWASP Amass: Used for attack surface and asset discovery.
• OWASP WebGoat and OWASP Juice Shop: Intentionally vulnerable applications built for security training.
• OWASP CycloneDX: An important standard and tooling ecosystem for software bill of materials (SBOM) and supply chain visibility.

This training focuses on the OWASP Top 10, but the broader OWASP mindset matters when reading the categories: the goal is not only to memorize vulnerability names, but to connect secure design, secure development, testing, operations, and incident response.

Short History of the OWASP Top 10

The OWASP Top 10 project is one of the best-known OWASP efforts in web application security. The official OWASP Top Ten Web Application Security Risks page lists OWASP Top Ten 2025 as the current release, with previous versions including 2021 and 2017. The project first appeared in 2003 to provide a practical starting point for application security risks and has since become a shared reference for developers, security teams, auditors, training programs, and security tools.

The Top 10 is updated periodically, but not on a rigid calendar. A new release does not simply count “the most common vulnerabilities.” It uses contributed data, CVE/CWE mappings, exploitability and impact assessment, and community input from application security practitioners. For that reason, the OWASP Top 10 is data-informed but not blindly data-driven; it is designed to provide practical awareness, not only historical statistics.

How to Read OWASP Top 10:2025

The official OWASP Top 10:2025 release positions the list as a current awareness document for web application security. In this training, we will treat the list not as ten headings to memorize, but as a practical framework for classifying and fixing real web application weaknesses.

OWASP Top 10 categories usually represent families of weaknesses with similar root causes, not a single vulnerability. For example,

A05:2025 Injection

is not only SQL Injection; it also includes OS command injection, NoSQL injection, LDAP injection, XSS, and similar interpreter-based issues. Likewise,

A01:2025 Broken Access Control

can appear as IDOR, privilege escalation, CORS mistakes, SSRF, and missing API authorization.

The official 2025 list contains these categories:

Code	Category	Short Meaning
A01:2025	Broken Access Control	Users can access data or functions outside their intended permissions
A02:2025	Security Misconfiguration	Insecure configuration in the application, framework, cloud, server, or security headers
A03:2025	Software Supply Chain Failures	Trust failures in dependencies, builds, artifacts, CI/CD, or distribution infrastructure
A04:2025	Cryptographic Failures	Sensitive data is protected with weak, missing, or incorrect cryptography
A05:2025	Injection	Untrusted input is executed by an interpreter as a command or query
A06:2025	Insecure Design	Security controls are missing or ineffective at the design level
A07:2025	Authentication Failures	Flaws in authentication, credential recovery, MFA, or session handling
A08:2025	Software or Data Integrity Failures	Code, updates, serialized data, or critical data are trusted without integrity verification
A09:2025	Security Logging and Alerting Failures	Security events are not logged, monitored, alerted, or acted on effectively
A10:2025	Mishandling of Exceptional Conditions	Error handling, abnormal state, failing open, and exception handling flaws

What Changed in the 2025 Version?

OWASP Top 10:2025 makes root-cause-oriented classification more explicit than earlier versions. The OWASP 2025 Introduction states that this release includes two new categories and one consolidation.

Important changes include:

• A03:2025 Software Supply Chain Failures

  expands the older “Vulnerable and Outdated Components” scope to include dependencies, build pipelines, artifact repositories, package registries, and distribution infrastructure.

• A10:2025 Mishandling of Exceptional Conditions

  introduces improper exception handling, failing open, logic errors, and abnormal state handling as a separate category.

• Server-Side Request Forgery (SSRF)

  is no longer a standalone 2021 category and is now covered under

  A01:2025 Broken Access Control

  .

• A09:2025 Security Logging and Alerting Failures

  emphasizes actionable alerting and incident response, not only log generation.

Training Approach

Each OWASP category is covered in a separate section. Every section explains what the risk is, why it appears, how an attacker may recognize it, example HTTP request/response behavior, evidence to collect during testing, and defensive controls that reduce the risk.

When evaluating a web vulnerability, asking whether the payload worked is not enough. A high-quality security finding is supported by:

• Affected endpoint and HTTP method
• Required privilege level and attacker prerequisite
• Successful and failed request comparison
• Data impact: read, modify, delete, financial transaction, account takeover
• Missing defense: absent control, wrong control location, wrong trust boundary
• Reproducibility and business impact

Core Concepts

Trust boundary is the logical boundary between trusted and untrusted zones. A browser, mobile app, reverse proxy, backend service, database, and third-party service may each sit across different trust boundaries.

Server-side enforcement means a security decision is made in trusted server-side code that the attacker cannot modify. Hiding a button, hiding a route, or checking permissions only in JavaScript is not a security control.

Fail closed means the system moves to the safer default when an error occurs. If the authorization service is unavailable, rejecting the transaction is fail closed; approving it is fail open.

Positive validation means explicitly defining the format that is allowed. It is more reliable than trying to block dangerous characters because it states what the application accepts.

Simple Risk Reading Example

The following request may not prove a vulnerability by itself, but it demonstrates the testing mindset. The attacker requests a record that does not belong to their account by changing the

id

parameter:

GET /api/orders/78391 HTTP/1.1
Host: vulnerable-app.example
Cookie: session=standard_user_session

If the application only checks the

id

value and does not verify whether the order belongs to the session user, the issue falls under

A01:2025 Broken Access Control

. If the same endpoint returns stack traces during errors, it also relates to

A10:2025 Mishandling of Exceptional Conditions

; if the attempt is not logged or alerted, it also touches

A09:2025 Security Logging and Alerting Failures

.

OWASP Top 10 categories are therefore not completely isolated in practice. A finding has one primary category, but it may also reveal secondary risks.