What Is the OWASP Top 10?
A developer pushes code on Friday afternoon. By Monday, an attacker has manipulated an API parameter, accessed customer records, and exfiltrated them through a broken access control flaw that a simple authorization check would have stopped. This is the kind of vulnerability the OWASP Top 10 exists to prevent.
The OWASP Foundation defines the OWASP Top 10 as "a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications." The list has gone through multiple editions, and the 2025 introduction introduced structural changes that reflect how the application security landscape has shifted.
NIST and the MITRE CWE Content Team formally reference OWASP Top 10 categories in their own frameworks. If you run a security program, build applications, or manage vulnerability response, the OWASP Top 10 is the baseline your stakeholders expect you to address. Here is what the current edition covers and how each category applies to your environment.
The 2025 OWASP Top 10 Categories
The 2025 edition reshuffled priorities based on real-world data. Here are all ten categories in their current ranking, with the changes that matter for your security program.
A01: Broken Access Control
Still the top category, with 3.73% of tested applications showing at least one related flaw. Broken access control allows users to act outside their intended permissions, whether by modifying a URL parameter to view another user's records, escalating privileges through JWT token manipulation, or bypassing function-level restrictions entirely. This covers insecure direct object references (IDOR), missing access controls, and CORS misconfigurations. SSRF, previously a standalone category, is now consolidated here.
A02: Security Misconfiguration
Moved up from #5 in 2021, reflecting how much modern application behavior depends on configuration rather than code. This category covers default credentials left unchanged, unnecessary services exposed, verbose error messages leaking stack traces, and missing security headers. Cloud environments and containerized deployments have amplified the risk because each new service, API gateway, or Kubernetes cluster introduces its own configuration surface.
A03: Software Supply Chain Failures
The most notable structural change in the 2025 edition. Previously scoped to "Vulnerable and Outdated Components," this category now covers the entire ecosystem of software dependencies, build systems, and distribution infrastructure. Attackers increasingly target CI/CD pipelines, developer tooling, container registries, and widely used open-source packages rather than application code directly. Despite fewer occurrences in the data, this category carries the highest average exploit and impact scores in the 2025 dataset.
A04: Cryptographic Failures
Renamed from "Sensitive Data Exposure" to focus on root causes rather than symptoms. This category covers data transmitted in cleartext, deprecated hash functions (MD5, SHA1), passwords used as cryptographic keys, and insufficient randomness. When cryptographic protections fail, attackers can intercept credentials in transit, decrypt stored data, or forge authentication tokens. The rename reflects OWASP's broader shift toward addressing why data gets exposed rather than cataloging exposure events after the fact.
A05: Injection
Injection occurs when an application passes untrusted input to an interpreter without proper validation or escaping, allowing attackers to execute unintended commands. SQL injection, cross-site scripting (XSS), OS command injection, and LDAP injection all fall under this category. Although injection dropped from #3 to #5 in the 2025 ranking, it still carries one of the highest numbers of associated CVEs and remains a leading cause of data breaches when input handling is neglected.
A06: Insecure Design
This category addresses architectural and design-level flaws rather than implementation bugs. A weak password-reset flow, a missing authorization step in a business workflow, or the absence of rate limiting on a sensitive endpoint are all design decisions, and no amount of secure coding can fix a fundamentally insecure design. OWASP introduced this category to emphasize threat modeling, secure design patterns, and pre-code security activities. Its drop from #4 to #6 in 2025 suggests the industry is gradually improving in this area.
A07: Identification and Authentication Failures
This category covers weaknesses that let attackers compromise user identities: credential stuffing, brute-force attacks against weak passwords, missing multi-factor authentication (MFA), and session management flaws like predictable session tokens or improper invalidation. OWASP's analysis notes that increased use of standardized authentication frameworks is having a positive effect on occurrence rates, though stolen credentials remain one of the most common initial access vectors in breaches.
A08: Software or Data Integrity Failures
This category targets assumptions of trust in software updates, CI/CD pipelines, and data serialization. When applications auto-update without verifying signatures, pull dependencies from unverified sources, or deserialize untrusted data without validation, attackers can inject malicious code that executes with full application privileges. The category also covers CI/CD pipeline integrity, where a compromised build step can ship malicious artifacts to production undetected.
A09: Security Logging and Alerting Failures
The rename from "Security Logging and Monitoring Failures" is deliberate: "Alerting" replaced "Monitoring" because, per OWASP's 2025 introduction, "great logging with no alerting is of minimal value" in identifying security incidents. Without actionable alerting tied to log sources, breaches go unnoticed while evidence sits in storage. This category also covers insufficient log detail, missing audit trails for sensitive actions, and logs that fail to capture authentication or access control events.
A10: Mishandling of Exceptional Conditions
New in the 2025 edition, this category addresses what happens when applications encounter unexpected inputs, resource shortages, timeouts, or internal failures. Poor exception handling can leak sensitive data through verbose stack traces, bypass security controls through fail-open logic, or create denial-of-service conditions. OWASP consolidated 24 CWEs previously scattered across "code quality" issues into this category, reflecting growing recognition that brittle systems that break unsafely are a distinct and exploitable class of risk.
The table below summarizes each category and what shifted in the 2025 edition.
| # | Category | What changed in 2025 |
| A01 | Broken Access Control | Now includes SSRF, previously a standalone category |
| A02 | Security Misconfiguration | Moved up from #5 in 2021 |
| A03 | Software Supply Chain Failures | Expanded from "Vulnerable and Outdated Components" to cover the full dependency ecosystem |
| A04 | Cryptographic Failures | Moved down from #2; focus remains on root-cause encryption issues |
| A05 | Injection | Dropped from #3 to #5; still one of the most tested categories |
| A06 | Insecure Design | Dropped from #4 to #6; industry adoption of threat modeling is improving |
| A07 | Authentication Failures | Unchanged position; slight name update from "Identification and Authentication Failures" |
| A08 | Software or Data Integrity Failures | Unchanged position |
| A09 | Security Logging and Alerting Failures | Renamed; "Alerting" replaces "Monitoring" to reflect operational need |
| A10 | Mishandling of Exceptional Conditions | New category; replaces the former SSRF entry |
These categories define the baseline. Before looking at how to fix each one, it helps to understand why these specific risks carry organizational weight.
Why the OWASP Top 10 Matters
The gap between vulnerability discovery and exploitation continues to narrow, and web applications remain a primary entry point. For your organization, the OWASP Top 10 matters for three reasons.
- Risk prioritization. You cannot fix everything simultaneously. The Top 10 gives you a data-driven starting point ranked by exploitability and impact, not theoretical severity alone.
- Regulatory alignment. The NIST CSF maintains crosswalk mappings to OWASP Top 10 variants. When auditors or regulators ask about your application security program, the OWASP Top 10 is the common language.
- Financial reality. Security failures in access control, misconfiguration, and injection can become expensive incidents. The OWASP Top 10 helps your teams focus on the vulnerability classes most likely to create operational and business impact.
Understanding why these risks matter is the first step. The next is knowing how to address each one at the code and configuration level.
How to Prevent OWASP Top 10 Vulnerabilities
Each OWASP Top 10 category has specific prevention steps your teams can implement directly.
- A01: Broken access control. Enforce deny-by-default on all endpoints. Validate permissions server-side on every request, and consolidate to a single access control routine applied consistently across the codebase. Disable directory listing and ensure CORS policies restrict origins to trusted domains.
- A02: Security misconfiguration. Remove default credentials, disable unused services and features, and automate configuration audits across environments. Keep security headers current and ensure error messages return generic responses rather than stack traces.
- A03: Software supply chain failures. Pin dependencies to specific versions and verify integrity with cryptographic signatures or checksums. Maintain a software bill of materials (SBOM), audit CI/CD plugins and developer tooling, and monitor vulnerability databases for disclosed flaws in your dependency tree.
- A04: Cryptographic failures. Use current encryption standards (TLS 1.2+, AES-256) and retire deprecated algorithms like MD5 and SHA1. Store passwords with adaptive hashing functions like bcrypt or Argon2. Classify data by sensitivity so you apply the right level of protection to the right assets.
- A05: Injection. Use parameterized queries for all database operations. Validate and sanitize all user input, and escape output for the specific rendering context (HTML, JavaScript, SQL). Apply content security policies to reduce XSS impact.
- A06: Insecure design. Conduct threat modeling before writing code, establish abuse case testing alongside functional tests, and apply secure design patterns from the OWASP Proactive Controls. Design flaws are cheaper to fix in architecture than in production.
- A07: Authentication failures. Enforce MFA, implement login throttling with maximum attempt limits, and use standardized authentication frameworks. Invalidate sessions properly on logout and password change.
- A08: Software or data integrity failures. Cryptographically sign all build artifacts, container images, and software updates. Validate deserialization input and restrict CI/CD pipeline write access to authorized roles only.
- A09: Security logging and alerting failures. Configure actionable alert thresholds for authentication failures, access control violations, and privilege escalation attempts. Test that alerts fire under real conditions, not only that logs are ingested.
- A10: Mishandling of exceptional conditions. Define secure failure modes that fail closed and deny access on error. Return generic error messages to users while logging detailed diagnostics internally. Handle null values, resource exhaustion, and unexpected input types explicitly.
Per-category prevention addresses the technical fixes. Scaling those fixes across your organization is where implementation challenges emerge.
Challenges and Common Mistakes in OWASP Top 10 Implementation
Operationalizing the OWASP Top 10 across a production environment with hundreds of applications, dozens of development teams, and continuous deployment cycles is where implementation breaks down. These are the patterns that cause the most damage.
- Treating the Top 10 as a pass/fail checklist. OWASP explicitly describes the Top 10 as an awareness guide, not a security program. For verification-level testing, OWASP recommends the ASVS. For supply chain coverage alone, the Top 10 is characterized as only "Occasionally" sufficient.
- Fragmented access control implementations. The Proactive Controls project warns against having multiple access control implementations scattered across a codebase. One flawed implementation remains exploitable even when all others are correct.
- Permissive-by-default configurations. Not enforcing deny-by-default across REST APIs and webhooks means any unaddressed endpoint is implicitly accessible. This applies to cloud services, Kubernetes RBAC, and API gateways alike.
- Authorization at scale. Authentication is improving, but access control is not. The industry is solving "who are you?" but struggling with "what should you be allowed to do?" across APIs and microservices.
- Logging without alerting. You may have terabytes of log data ingested into your SIEM, but if no one configures actionable alert thresholds, incidents go unnoticed while evidence sits in storage.
- Relying exclusively on enumeration-based scanning. Enumeration-based tools can only find what you already know to look for. Logic flaws, novel misconfigurations, and architectural weaknesses require behavioral analysis, not signature matching alone.
These patterns persist when security programs treat the OWASP Top 10 as a one-time audit rather than an ongoing operational practice.
OWASP Top 10 Best Practices
Beyond per-category fixes, these program-level practices help you operationalize the OWASP Top 10 across your organization.
- Build a centralized security control library. Per program guidance, define shared, reusable libraries for authentication, authorization, input validation, and cryptography. When every team builds their own implementation, inconsistencies create exploitable gaps.
- Map Proactive Controls to your development workflow. The Proactive Controls provide a developer-facing complement to the risk-focused Top 10. C1 (Access Control) maps to A01, C3 (Input Validation) maps to A05, C5 (Secure Defaults) maps to A02. Give your developers specific controls to implement, not risks to avoid.
- Use OWASP ASVS as your verification baseline. Replace ad-hoc penetration testing with structured, ASVS requirements mapped to each Top 10 category. ASVS provides testable criteria in CSV and JSON formats for programmatic integration.
- Integrate with NIST SSDF for regulatory alignment. NIST SP 800-218 explicitly references OWASP ASVS, OWASP SAMM, and OWASP SCVS as complementary frameworks and aligns with Executive Order 14028 requirements.
These practices create the programmatic foundation. Testing validates that your prevention controls work as expected.
How to Test for the OWASP Top 10
No single tool covers all ten categories. Effective OWASP Top 10 testing combines static analysis, dynamic testing, and composition analysis to cover code-level, runtime, and dependency risks.
- Static application security testing (SAST) scans source code for injection patterns, cryptographic weaknesses, and authentication flaws before deployment. SAST catches issues early in the development cycle when fixes are cheapest.
- Dynamic application security testing (DAST) tests running applications for access control gaps, misconfigurations, and error handling failures by simulating real attack traffic against live endpoints. OWASP ZAP is a widely used open-source DAST tool maintained by the OWASP community.
- Software composition analysis (SCA) identifies known vulnerabilities in third-party libraries, frameworks, and container images by tracking your dependency tree against published vulnerability databases.
- Penetration testing validates your specific environment, catching logic flaws and architectural weaknesses that automated tools miss. Map penetration test findings to ASVS requirements for structured verification.
The table below maps each testing method to the OWASP Top 10 categories it covers most directly.
Method | Categories covered | Best used |
SAST | A04, A05, A07 | During development, before code is merged |
| DAST | A01, A02, A10 | Against running applications in staging or production |
| SCA | A03, A08 | During build and on every dependency update |
| Penetration testing | All 10 categories | Periodic validation, after major releases |
Combining these methods gives you coverage across all ten OWASP Top 10 categories. Autonomous tooling closes the execution gap between what you find and how fast you respond.
Key Takeaways
The OWASP Top 10 is the industry's standard awareness framework for web application security risks, updated in 2025 with expanded supply chain coverage and a new emphasis on alerting alongside logging. Broken Access Control remains the top category. Each category has specific, implementable prevention steps, from deny-by-default access controls to cryptographic artifact verification.
Effective implementation requires centralized security controls, layered testing across SAST, DAST, and SCA, and autonomous investigation that closes the gap between exploit speed and response speed.
FAQs
The OWASP Top 10 is a standard awareness document published by the OWASP Foundation that identifies the most critical security risks to web applications.
Based on real-world vulnerability data and community surveys, the list provides a consensus-driven ranking that developers, security teams, and auditors use as a baseline for application security programs. The current edition was released in 2025.
The OWASP Top 10 does not follow a fixed release schedule. Updates are published when sufficient new vulnerability data and community input justify a revised ranking.
Previous editions were released in 2013, 2017, 2021, and 2025. Each update reflects shifts in real-world exploitation patterns, changes in application architecture, and new data collection methodologies rather than theoretical risk projections alone.
The Top 10 is an awareness document designed to highlight the most critical risk categories for web applications. The ASVS (Application Security Verification Standard) provides structured, testable verification requirements at three assurance levels, making it suitable for security testing and code review.
OWASP itself recommends ASVS for design reviews and security assessments, positioning the Top 10 as an entry point and ASVS as the verification framework.
The web application Top 10 covers API-relevant categories, especially Broken Access Control (A01) and Injection (A05). However, OWASP maintains a separate API Security Top 10 with categories specific to API authorization, rate limiting, and object-level access control.
Several leading API risks relate directly to authorization failures that mirror A01. Organizations with significant API exposure should address both lists to ensure adequate coverage.
The 2025 methodology expanded the analyzed dataset and introduced a broader data contribution cycle alongside OWASP's community survey component for forward-looking risks.
The weighting formula continued to balance exploitability and technical impact while reflecting a broader vulnerability corpus. This methodological expansion, not shifting threat patterns alone, drove several ranking changes, including Security Misconfiguration's rise and the addition of Mishandling of Exceptional Conditions as a new category.
No. OWASP explicitly states the Top 10 is an awareness and entry-level training tool. For supply chain security alone, the Top 10 is characterized as only "Occasionally" sufficient.
A full program should incorporate OWASP ASVS for verification, OWASP SAMM for maturity assessment, NIST SSDF for SDLC integration, and continuous runtime protection to cover risks the Top 10 was never designed to address.
