OWASP Top 10:2025
The ten most critical web application security risks in the current OWASP Top 10:2025: what changed since 2021 and how to defend against each risk.
What is the OWASP Top 10?
The OWASP Top 10 is an awareness document from the OWASP community (Open Worldwide Application Security Project) that summarises the ten most critical security risks to web applications. The current edition is the eighth, OWASP Top 10:2025. It was presented as a release candidate in November 2025 at OWASP Global AppSec in Washington, D.C., and is now released as final. OWASP marks the 2021 edition as superseded.
How it is built and what it is for
The list combines application testing data with practitioner input. OWASP itself calls it "data-informed, but not blindly data-driven".
- Data from more than 2.8 million applications, contributed by organisations such as Veracode, Sonar, Semgrep, Contrast Security, Bugcrowd and Accenture.
- It measures prevalence, not frequency. What counts is the share of tested applications with at least one instance of a weakness. Four findings and four thousand findings in one application count the same.
- 589 CWEs analysed (just under 400 in 2021). 248 of them are mapped into the ten categories, with at most 40 per category.
- Eight categories come from the data, two from the community survey. The survey captures risks that automated testing measures poorly. This time it brought in the supply chain (A03) and logging and alerting (A09).
- Categories are ranked by risk: prevalence plus the average CVSS exploitability and impact scores of the CVEs mapped to them.
The Top 10 is not a checklist
The OWASP Top 10 is an awareness document and a good starting point for priorities and training. For verifying and testing an application, OWASP recommends the ASVS (Application Security Verification Standard). Risks specific to LLM applications, such as prompt injection, are covered by the separate OWASP Top 10 for LLM Applications.
What changed since 2021
- New category A03 Software Supply Chain Failures. It expands the former "Vulnerable and Outdated Components" from vulnerable libraries to the whole chain: dependencies, build systems, CI/CD and distribution. Exactly half of the community survey respondents ranked it first.
- New category A10 Mishandling of Exceptional Conditions. Improper handling of errors and unexpected states. It also absorbs CWEs that used to fall under "poor code quality".
- SSRF is no longer a separate category. Server-Side Request Forgery is now part of A01 Broken Access Control.
- Security Misconfiguration rose from 5th to 2nd. Software behaviour is increasingly driven by configuration, and so are its mistakes.
- Renames: "Identification and Authentication Failures" is now "Authentication Failures", "Logging and Monitoring" became "Logging and Alerting", and "Software and Data Integrity" became "Software or Data Integrity".
| 2025 | Category | 2021 |
|---|---|---|
| A01 | Broken Access Control (now including SSRF) | A01 (SSRF was A10) |
| A02 | Security Misconfiguration | A05 ↑ |
| A03 | Software Supply Chain Failures | new, expands A06 |
| A04 | Cryptographic Failures | A02 ↓ |
| A05 | Injection | A03 ↓ |
| A06 | Insecure Design | A04 ↓ |
| A07 | Authentication Failures | A07 |
| A08 | Software or Data Integrity Failures | A08 |
| A09 | Security Logging and Alerting Failures | A09 |
| A10 | Mishandling of Exceptional Conditions | new |
OWASP Top 10:2025, the complete list
Categories are ranked by risk. The figures under each description come from the official category pages: max incidence is the share of affected applications at the contributor with the highest rate, CVEs is the number of known vulnerabilities mapped to the category's CWEs.
Broken Access Control
2021: A01
What it is: A user or system reaches data or functions it should not have access to. SSRF now belongs here too: the attacker makes the server send a request to a target of their choice, such as an internal service or the cloud metadata endpoint.
100% of tested applications had some form · max incidence 20.15% · 40 CWEs · 32,654 CVEs
Typical mistakes:
- IDOR: changing
?acct=123in the URL shows someone else's account - Access checks only in the front end, so the API can be called directly
- Missing checks on POST, PUT and DELETE endpoints
- JWT or cookie tampering, overly permissive CORS
- SSRF to
http://169.254.169.254/(cloud metadata)
How to defend:
- Enforce access control only in trusted server-side code
- Deny by default for everything except public resources
- One shared authorization mechanism instead of checks scattered across the code
- Enforce record ownership in the data model
- Short-lived JWTs, invalidate sessions on logout
- Authorization tests as part of unit and integration tests
Security Misconfiguration
2021: A05 ↑
What it is: A system, application or cloud service is configured insecurely: missing hardening, unnecessary services running, default passwords left in place or detailed errors leaking out.
100% of tested applications had some form · max incidence 27.70% (highest of all) · 719,084 occurrences
Typical mistakes:
- Default accounts and sample applications in production
- Publicly accessible S3 buckets or storage accounts
- Stack traces returned to users, debug mode enabled
- Missing security headers, cookies without HttpOnly
- XXE caused by default XML parser settings
How to defend:
- Repeatable, automated hardening through Infrastructure as Code
- Dev, test and production configured identically, differing only in credentials
- A minimal platform without unnecessary features
- Automated configuration checks in every environment (Checkov, Trivy, CSPM)
- Identity federation and short-lived credentials instead of static secrets in code and pipelines
Software Supply Chain Failures New
Expands A06:2021
What it is: Compromises or failures in building, distributing or updating software. Vulnerable or malicious dependencies, untracked transitive libraries, unmaintained components, and a CI/CD pipeline that is weaker than the systems it deploys.
Highest average incidence and highest average exploit and impact scores of all categories · ranked #1 by 50% of survey respondents
Real-world examples:
- SolarWinds (2019): a tampered update, around 18,000 organisations affected
- Bybit (2025): USD 1.5 billion stolen through compromised wallet software
- Shai-Hulud (2025): a self-propagating npm worm, over 500 package versions
- Log4Shell (CVE-2021-44228) hiding in untracked dependencies
How to defend:
- A centrally managed SBOM including transitive dependencies
- Continuous component tracking (Dependency-Track) against CVE, NVD and OSV
- Packages only from official sources, preferably signed
- MFA and least privilege for repositories, CI/CD and registries
- Signed builds, provenance (SLSA), immutable artifacts
- Staged (canary) rollouts so a compromised version is caught early
Cryptographic Failures
2021: A02 ↓
What it is: Missing or weak cryptography, leaked keys and mistakes in how cryptography is used. The most common consequence is exposure of sensitive data.
Max incidence 13.77% · 32 CWEs · 1,665,348 occurrences
Typical mistakes:
- Data sent without TLS, downgrade to HTTP possible
- MD5 or SHA-1, passwords hashed with a fast unsalted algorithm
- Keys in the repository, default or reused keys
- Weak random number generator, ECB mode
- Certificates not validated
How to defend:
- Classify data and do not store sensitive data unnecessarily
- Encrypt sensitive data at rest and in transit, TLS 1.2+ only with forward secrecy and HSTS
- Store passwords with Argon2, scrypt, yescrypt or PBKDF2
- Keep the most sensitive keys in an HSM or cloud KMS
- Always use authenticated encryption (e.g. AES-GCM)
- Prepare for post-quantum cryptography, for high-risk systems by the end of 2030 at the latest
Injection
2021: A03 ↓
What it is: Untrusted input reaches an interpreter (database, shell, browser) and is executed as a command. This covers SQL, NoSQL, OS command, LDAP and Expression Language injection, as well as XSS.
Most CVEs of any category: 62,445 · XSS over 30,000 CVEs, SQL injection over 14,000
SQL injection example:
How to defend:
- Keep data separate from commands: parameterized queries, a safe API or an ORM
- Watch out for stored procedures using
EXECUTE IMMEDIATEorexec() - Positive server-side input validation (as a complement, not the only defence)
- Context-aware output encoding against XSS
- SAST, DAST and fuzzing in CI/CD
Insecure Design
2021: A04 ↓
What it is: Flaws in design and architecture, including business logic flaws. OWASP sums it up: an insecure design cannot be fixed by a perfect implementation.
Max incidence 22.18% · 39 CWEs · 7,647 CVEs
Examples:
- Password recovery through security questions (prohibited by NIST 800-63b)
- A cinema group discount abused to book 600 seats in a few requests
- Bots buying up limited-stock goods
- Unrestricted upload of dangerous file types
How to defend:
- Threat modeling for authentication, authorization, business logic and key flows
- A library of secure design patterns and vetted components ("paved road")
- Security requirements written into user stories
- Tests for misuse cases, not only for correct use
- Separation of tiers and tenants
Authentication Failures
2021: A07
What it is: An attacker tricks the system into treating them as a legitimate user. Weak passwords, credential stuffing, missing MFA or poor session management.
Max incidence 15.80% · 36 CWEs · 7,147 CVEs
Typical mistakes:
- Credential stuffing and password spraying (Winter2025 → Winter2026)
- Default, weak or breached passwords
- Missing MFA or a weak fallback method
- Session IDs in URLs, session fixation, no single logout across SSO
- Unvalidated
audandissclaims in JWTs
How to defend:
- MFA wherever possible, and support for password managers
- Check new passwords against breached-password lists
- No forced periodic password rotation (NIST 800-63b), only on suspected compromise
- Identical error messages so accounts cannot be enumerated
- Limit and slow down failed attempts, alert on attacks
- A proven solution (OIDC, an IdP) instead of a home-grown implementation
Software or Data Integrity Failures
2021: A08
What it is: The application or infrastructure does not maintain trust boundaries or verify the integrity of code, artifacts and data. Compared with A03, this sits at a more specific, technical level.
Max incidence 8.98% · 14 CWEs · 3,331 CVEs
Typical mistakes:
- Scripts and libraries from untrusted CDNs without integrity checks
- CI/CD pulls and deploys unverified artifacts
- Auto-updates without signature verification
- Insecure deserialization of client data
How to defend:
- Verify digital signatures of software and data
- Subresource Integrity for scripts loaded from CDNs
- Dependencies only from trusted or internal repositories
- Review of code and configuration changes, segregated and controlled CI/CD
- Never deserialize unsigned data from untrusted clients
Security Logging and Alerting Failures
2021: A09
What it is: Security events are not logged, nobody watches the logs, or no alert and response follow. The rename from "monitoring" to "alerting" is deliberate: according to OWASP, great logging with no alerting is of minimal value.
Voted in by the community survey for the third time · only 723 CVEs, because it is hard to test
Typical mistakes:
- Failed logins and denied access are not logged
- No alert thresholds or escalation, a DAST scan triggers no alert
- Sensitive data in logs, log injection
- So many false positives that a real attack goes unnoticed
How to defend:
- Log authentication, authorization and validation failures with user context
- A machine-readable format and central collection (SIEM)
- Append-only audit trails protected against tampering
- Alerts tied to playbooks and an incident response plan
- Honeytokens as cheap intrusion detection
Mishandling of Exceptional Conditions New
New in 2025
What it is: A program fails to prevent, detect or properly respond to an abnormal situation. The results are crashes, logic bugs, race conditions, fraudulent transactions and systems that fail open.
Max incidence 20.67% · 24 CWEs · 3,416 CVEs
Typical mistakes:
- Error messages with sensitive details (stack traces, SQL)
- An exception during file upload never releases resources, leading to DoS
- An interrupted money transfer is not rolled back and is debited or credited more than once
- An authorization check lets the request through when it errors
How to defend:
- Catch errors where they occur and handle them meaningfully
- A global exception handler as the last safety net
- Roll back the whole transaction on error and fail closed
- Limits, quotas and throttling: nothing in IT should be limitless
- Consistent error handling, logging and alerting across the organisation
What to do first
If you have been working from the 2021 edition, these steps cover most of what the new edition brings:
- Map your supply chain (A03). Generate an SBOM in CI/CD, track dependencies continuously rather than only at build time, and enforce MFA and least privilege for repositories, pipelines and registries. More in our articles on SCA and CI/CD security.
- Check configuration automatically (A02). Scan IaC and live cloud accounts, not only application code. See Infrastructure as Code security.
- Add SSRF to your authorization tests (A01). Restrict outbound traffic from applications and enforce IMDSv2 in AWS.
- Review error handling (A10). Look for places where an exception lets a request through, fails to roll back a transaction, or returns internal details to the user.
- Connect logs to alerts (A09). Check that a penetration test or DAST scan triggers an alert, and that someone responds to it. See security monitoring and logging.
- Update your mappings. SAST/DAST rules, security questionnaires, internal standards and training often reference 2021 category numbers (A03:2021 Injection is now A05:2025).
How to implement protection
The DevSecOps approach
Protection against the OWASP Top 10 requires security across the whole lifecycle, from design to operations:
1. Design
- Threat modeling (A06)
- Security requirements in user stories
- Architecture review
2. Development
- SAST (A05, A10)
- SCA and SBOM (A03)
- Secret detection in code (A04, A07)
3. Build
- Signed artifacts and provenance (A03, A08)
- Hardened CI/CD with MFA and least privilege
- Container scanning
4. Testing
- DAST (A01, A02, A05)
- Authorization tests and misuse cases
- Penetration tests based on ASVS
5. Deployment
- IaC and configuration scanning (A02)
- Security gates in CI/CD
- Canary deployments (A03)
6. Operations
- Central logging and alerting (A09)
- Continuous dependency tracking (A03)
- Incident response playbooks
Recommended tools
- SAST: Semgrep, CodeQL, SonarQube, Checkmarx
- DAST: ZAP, Burp Suite
- SCA and SBOM: OWASP Dependency-Track, Syft, Snyk, Dependabot, Renovate
- Signing and provenance: Sigstore (cosign), SLSA, GitHub Artifact Attestations
- IaC and configuration: Checkov, Trivy, KICS
- Containers: Trivy, Grype
- Secret detection: Gitleaks, TruffleHog, GitGuardian
- WAF: AWS WAF, Azure WAF, Cloudflare
Sources
- OWASP Top 10:2025: official text and category pages
- OWASP Top 10:2025 Introduction: methodology, data and changes since 2021
- OWASP/Top10 on GitHub: source texts and release status
- OWASP ASVS: the application security verification standard
- OWASP Top 10 for LLM Applications: risks of applications built on language models