OWASP Top 10 2025: what changed and how to act in 2026
The OWASP Top 10:2025 changes how teams should think about application risk. This practical guide explains the new categories, ranking shifts, and the security priorities worth carrying into 2026.
The OWASP Top 10 is one of the most recognizable starting points in application security. Its 2025 edition is the first major update since 2021, and the changes are more meaningful than a reshuffled ranking. They reflect the growing influence of configuration, software supply chains, delivery systems, and failure behavior on real-world application risk.
For teams planning security work in 2026, the useful question is not “Which ten labels should we add to a dashboard?” It is “Which assumptions, controls, and testing practices need to change?” This guide answers that question without treating the list as a complete security standard or a substitute for application-specific risk analysis.
2.8M+
applications represented
Contributed data gives the 2025 edition a broad view of weaknesses found across real application testing.
589
CWEs analyzed
OWASP expanded the weakness population reviewed, compared with approximately 400 CWEs in the 2021 cycle.
248
CWEs in the final categories
The ten categories group related root causes so teams can connect awareness, testing, and remediation guidance.
2 + 1
new categories and consolidation
Supply chain and exceptional-condition risks join the list, while SSRF moves into Broken Access Control.
Source: OWASP Top 10:2025 introduction and methodology. The dataset covers more than 2.8 million applications; OWASP analyzed 589 CWEs and included 248 across the final ten categories.
What the OWASP Top 10 is, and what it is not
OWASP describes the Top 10 as an awareness document for developers and web application security. It organizes broad families of weakness so organizations can improve training, secure development, testing, and discussion between technical and business teams. The 2025 edition is data-informed, with two positions influenced by a community survey to account for risks that current testing may underrepresent.
Use it to
- Build shared awareness of major application security root causes.
- Review gaps in training, tooling, architecture, delivery, and operational controls.
- Connect individual findings to broader patterns that deserve systemic remediation.
Do not use it as
- A complete application security standard or proof of compliance.
- A universal severity order for every system, organization, or threat model.
- A reason to ignore important risks simply because they sit outside the ten categories.
A category moving down does not make its vulnerabilities less urgent. A SQL injection flaw that exposes customer data remains critical whether Injection is ranked third or fifth. Remediation priority should come from the weakness, affected asset, exploitability, exposure, data sensitivity, and business impact, not from the list position alone.
2021 to 2025 comparison
The complete OWASP Top 10:2025 change map
The list contains two new categories and one consolidation, alongside movement and naming changes. Reading the relationship between editions is more useful than comparing rank numbers in isolation.
Four changes that should influence 2026 security work
Configuration is part of the application
Security Misconfiguration moving from fifth to second place is a reminder that modern application behavior is spread across cloud policies, environment variables, container settings, framework defaults, HTTP headers, identity configuration, and infrastructure-as-code.
A secure codebase can still produce an exposed service when deployment defaults drift. Teams need versioned configuration, hardened baselines, automated checks, ownership, and verification of what is actually reachable after release.
Supply chain security is wider than CVE scanning
A03 expands the old vulnerable-components category into the complete path that brings software into production. Dependencies still matter, but so do registries, build services, CI/CD workflows, maintainers, update channels, artifacts, and deployment identities.
An effective program combines dependency inventory and vulnerability review with provenance, narrow pipeline permissions, signed artifacts, protected secrets, supplier assessment, and response plans for compromised components.
Failure paths deserve first-class testing
A10 gives a clear home to weaknesses that appear when systems enter an unexpected state. The security question is not whether errors happen; it is whether the application remains safe when they do.
Reviewers should test denied dependencies, timeouts, malformed state, concurrent actions, partial transactions, unavailable authorization services, and invalid responses. The safe outcome should be deliberate, observable, and fail closed where access is concerned.
SSRF changed category, not importance
Server-Side Request Forgery is now consolidated into Broken Access Control. That classification links the weakness to a central question: which network resources and destinations is the application allowed to reach on behalf of a user?
Existing SSRF controls still matter, including strict destination validation, outbound network restrictions, protected metadata services, safe URL parsing, and monitoring of unexpected server-side connections.
Application security now spans the full delivery lifecycle
The 2025 list makes a broader truth easier to see: application security is not confined to source code. Risk can enter before code is written, travel through a trusted build system, appear through configuration, or become visible only when a new endpoint reaches the internet.
Design
Risk: Missing abuse cases, unsafe trust boundaries, and controls that fail open.
Control: Threat modeling, security requirements, and explicit failure behavior.
Dependencies
Risk: Unreviewed packages, hidden transitive risk, or untrusted updates.
Control: SBOMs, dependency policy, provenance, and update review.
Build
Risk: Overprivileged pipelines, exposed secrets, and altered artifacts.
Control: Least privilege, protected workflows, signing, and isolated runners.
Deploy
Risk: Unsafe defaults, configuration drift, and unnecessary public access.
Control: Hardened baselines, policy checks, review, and environment parity.
Runtime
Risk: Access failures, injection, weak error handling, and missing alerts.
Control: Runtime testing, meaningful telemetry, alerting, and response.
External exposure
Risk: Unknown endpoints, stale services, leaked credentials, and shadow IT.
Control: Continuous discovery, validation, ownership, and retesting.
No single scanner covers this lifecycle. Secure design, code review, SAST, dependency analysis, pipeline protection, configuration validation, DAST, monitoring, incident response, and external attack surface discovery answer different questions. Coverage comes from combining them and assigning ownership to the gaps.
What each team should change
The Top 10 becomes useful when categories translate into accountable work. The following matrix connects the 2025 changes to actions and measurable outcomes without forcing every responsibility onto developers.
Engineering teams
Build secure behavior into normal delivery.
Threat model sensitive flows, test negative paths, use safe framework APIs, and treat configuration changes like code changes.
Platform and cloud teams
Reduce configuration and delivery-system drift.
Standardize secure templates, narrow CI/CD permissions, protect secrets, verify artifacts, and continuously compare deployed state with policy.
AppSec and security operations
Connect prevention, detection, and remediation.
Remap findings to 2025 categories, expand testing coverage, validate internet exposure, and turn meaningful events into actionable alerts.
Security leadership
Fund outcomes instead of checklist completion.
Set risk-based objectives, remove ownership gaps, review systemic causes, and measure whether important controls work in production.
Common OWASP Top 10 implementation mistakes
Most adoption problems are not caused by misunderstanding a category definition. They happen when a useful awareness document is turned into a narrow checkbox or disconnected from the way software reaches production.
Use the Top 10 for awareness and prioritization, then use ASVS, secure development practices, threat modeling, and risk-specific requirements for deeper coverage.
Combine the global list with your architecture, data sensitivity, threat model, business impact, exploitability, and real external exposure.
Cover dependencies, build pipelines, infrastructure configuration, runtime behavior, identities, third parties, and public assets too.
Define which events matter, who receives them, how quickly they must be investigated, and which context is required to make a decision.
Know what was built, from which inputs, by which trusted workflow, and whether the deployed artifact matches the approved release.
Trace each finding to its root cause and control failure so teams fix the system that produced the issue, not only the latest instance.
Action plan
A practical 30/60/90-day roadmap
Updating an application security program does not require rebuilding it in one quarter. Start by mapping the change, close the most important gaps, and then prove that the controls work in deployed systems.
Map the change
- Map existing policies, training, scanner rules, and reports from the 2021 categories to the 2025 list.
- Identify missing coverage for supply chain failures and exceptional conditions.
- List critical applications, owners, external assets, and current security evidence.
Outcome: one agreed coverage map with accountable owners and visible gaps.
Close priority gaps
- Harden deployment baselines and review high-risk configuration exceptions.
- Add SBOM, dependency, CI/CD permission, secret, and artifact controls to critical delivery paths.
- Add negative-path and fail-closed tests to sensitive application workflows.
Outcome: the highest-impact gaps have controls, evidence, and remediation dates.
Prove the controls work
- Validate applications dynamically and compare known inventory with the public attack surface.
- Test alert routes, incident ownership, and response for realistic application-security events.
- Create metrics for coverage, exposure age, recurrence, remediation speed, and accepted risk.
Outcome: leadership can see both control adoption and real production effectiveness.
Where external attack surface visibility fits
External attack surface management does not replace secure design, source analysis, dependency controls, or penetration testing. It answers a complementary question: what can an attacker actually discover and reach after applications, configurations, integrations, and infrastructure change?
Asset and endpoint discovery
Find internet-facing domains, subdomains, and application paths that may sit outside the expected inventory.
Technology visibility
Compare detected technologies and exposed software signals with the platforms teams believe they operate.
Certificate and identity context
Review SSL certificate status, ownership clues, and credential-leak signals around public assets.
Continuous validation
Retest after releases and infrastructure changes so a secure baseline does not become a stale assumption.
Splorix helps teams maintain that external view. Findings still require validation and context, but continuous discovery can reveal assets, endpoints, technology signals, certificate issues, and credential exposure that internal inventories or point-in-time reviews may miss.
Turn AppSec priorities into continuous external visibility
Discover public assets, endpoints, technologies, certificate signals, and exposed weaknesses as your applications and infrastructure evolve.
Continue learning
Software supply chain security
Build a practical defense across dependencies, CI/CD, artifacts, vendors, and public exposure.
DAST and production vulnerabilities
Understand how dynamic testing validates behavior that source review alone cannot prove.
SQL injection guide
Explore one of the best-known injection risks and the controls that prevent it.
Rate limit vulnerability guide
Learn how resource limits protect applications from automation, abuse, and exhaustion.
Endpoint tracker
See how endpoint discovery supports external application visibility.
Tech stack exposure checker
Review detected technologies and version signals across internet-facing assets.
Frequently asked questions
What is the OWASP Top 10:2025?
The OWASP Top 10:2025 is an awareness document describing ten major categories of web application security risk. It combines contributed testing data with practitioner input to highlight weaknesses that development and security teams should understand and address.
What are the new categories in the OWASP Top 10 2025?
The two new categories are A03 Software Supply Chain Failures and A10 Mishandling of Exceptional Conditions. A03 expands the former vulnerable-components category, while A10 covers unsafe error handling, fail-open behavior, race conditions, logical errors, and other abnormal states.
What happened to SSRF in the OWASP Top 10 2025?
Server-Side Request Forgery is no longer a standalone A10 category. OWASP consolidated SSRF into A01 Broken Access Control. The change does not reduce its importance or remove the need for outbound access controls, destination validation, and protected metadata services.
Why did Security Misconfiguration move to A02?
OWASP found misconfiguration to be more prevalent in the contributed data. The move also reflects how much application behavior now lives in cloud policies, framework settings, infrastructure-as-code, containers, identity configuration, and deployment environments.
Is the OWASP Top 10 a compliance standard?
No. OWASP describes the Top 10 as an awareness document. It is a strong starting point, but organizations need deeper requirements and verification practices such as OWASP ASVS, secure development frameworks, threat modeling, and risk-specific controls.
How should a company use the OWASP Top 10 in 2026?
Use it to update training, risk taxonomies, testing rules, secure design reviews, CI/CD controls, deployment baselines, and security reporting. Then prioritize work using the organization’s own architecture, data, threats, business impact, and public exposure.
Authoritative references
The category names, methodology, and dataset figures in this guide come from OWASP. The implementation advice also aligns with established secure software development and verification guidance from OWASP, NIST, and CISA.