OWASP Top 10: 2025 Changes and What to Fix First

Direct answer: The OWASP Top 10:2025 changes what application-security teams should inspect, but it does not give every organization a universal patch order. The biggest shifts are the expansion from vulnerable components to full software supply chain failures, the consolidation of server-side request forgery into broken access control, and a new category for mishandling exceptional conditions. Fix first by identifying exploitable paths to critical actions or data, mapping them to verifiable requirements, closing the root cause, and proving the saved and operating result.

This guide is a planning and verification framework. No live application, source repository, CI/CD pipeline, dependency graph, scanner, penetration test, or production alert was inspected for it. Your actual order must reflect your architecture, data, user roles, exposure, threat model, and legal obligations.

The OWASP Top 10:2025 in one view

The OWASP Top 10:2025 introduction describes two new categories and one consolidation. Several other categories moved or were renamed. The following table translates the list into a first verification question rather than pretending each category is a single scanner rule.

2025 category	Change from 2021	First verification question
A01 Broken Access Control	Remains first; now absorbs SSRF.	Can a user, service, or server-side request reach an object, action, network location, or tenant that its policy should deny?
A02 Security Misconfiguration	Moves from fifth to second.	Do deployed defaults, cloud resources, headers, permissions, error modes, and unused features match the approved secure baseline?
A03 Software Supply Chain Failures	Expands the former vulnerable-and-outdated-components category.	Can you identify, trust, update, and reproduce every dependency, build tool, artifact, and distribution step that can affect production?
A04 Cryptographic Failures	Moves from second to fourth.	Is sensitive data protected with appropriate, current cryptography and sound key, certificate, secret, and lifecycle management?
A05 Injection	Moves from third to fifth.	Are untrusted inputs separated from commands and queries across interpreters, templates, browsers, operating systems, and data stores?
A06 Insecure Design	Moves from fourth to sixth.	Does the design prevent abuse of workflows, trust boundaries, limits, and business rules before code-level controls are considered?
A07 Authentication Failures	Shorter name; stays seventh.	Can an attacker bypass, abuse, recover, or retain authentication through weak enrollment, sessions, rate limits, or account recovery?
A08 Software or Data Integrity Failures	Remains eighth with adjusted wording.	Does the application verify the origin and integrity of code, updates, serialized data, models, configuration, and other trusted inputs?
A09 Security Logging and Alerting Failures	“Monitoring” becomes “alerting.”	Do important security events produce useful, protected evidence and an alert that a responsible person or service can act on?
A10 Mishandling of Exceptional Conditions	New for 2025.	When input, state, privileges, dependencies, memory, or networks behave abnormally, does the system fail safely, preserve integrity, and recover predictably?

What changed—and why it changes the work

Supply chain risk is now wider than a dependency scan

A03 is not merely a new label for known vulnerable libraries. OWASP’s software supply chain guidance expands the boundary to dependencies, build systems, repositories, tools, artifact storage, distribution, updates, change control, privileges, and provenance. A software composition analysis result remains useful, but it cannot prove that a build runner is isolated, a release artifact is authentic, an update channel is protected, or one person cannot change and promote code without oversight.

Start by producing an inventory that connects source, direct and transitive dependencies, build identities, artifact locations, deployment permissions, and supported update paths. Remove unused components, track versions, protect pipeline credentials, restrict promotion rights, and test whether a patched or replaced dependency still works. EncryptCentral’s software supply chain and SBOM guide provides a deeper procurement and evidence framework for that work.

SSRF becomes part of access control

Server-side request forgery was A10 in 2021. In 2025 it is consolidated into A01 Broken Access Control. That framing is operationally useful: a server making a request is exercising access on behalf of something. Test what destinations it may reach, which protocols and redirects it follows, what credentials or metadata it can expose, how DNS and address validation behave, and whether outbound network policy provides a second boundary.

Do not reduce access-control testing to checking buttons or URL parameters. Include object-level, function-level, tenant, administrative, server-to-server, and network-destination authorization. Deny by default, centralize policy where practical, and test the policy from an attacker’s point of view.

Exceptional conditions become a security category

A10:2025 covers improper error handling, logic errors, failing open, and unsafe behavior when the system encounters abnormal conditions. The security question is not whether the application displays a friendly error page. It is whether incomplete input, unavailable dependencies, insufficient privileges, resource pressure, partial transactions, timeouts, and unexpected state cause the system to bypass controls, disclose sensitive details, corrupt data, repeat a transaction, or continue in an unknown state.

Build negative-path tests beside happy-path tests. Force missing and malformed parameters, permission failures, dependency timeouts, duplicate submissions, interrupted transactions, and unavailable downstream services in a safe environment. Verify that the system fails closed where required, rolls back consistently, limits sensitive error details, records a useful event, and alerts when the pattern may represent attack or material failure.

Logging must lead to action

The A09 wording change from monitoring to alerting is small but important. A stored log is not an operating control if no rule, owner, route, or response connects it to action. For a critical event, verify the complete chain: the application creates the right event, the event reaches the intended destination, access and retention are appropriate, an alert fires, the alert reaches an accountable owner, and the response is recorded. Static analysis may find missing log statements; it cannot prove that a production incident would be detected and handled.

Do not fix by rank alone

OWASP explains that the 2025 list is data-informed, not blindly data-driven. Contributed test data looks backward and naturally reflects what tools and testers can find. A community survey helps surface risks that are difficult to test or underrepresented. That makes the list valuable for awareness, but its global order cannot describe the business impact or exploit path in your application.

A public administrative authorization bypass may need immediate action even if another category has a higher average ranking. A cryptographic weakness protecting low-sensitivity test data may be less urgent than an exposed workflow that changes payment destinations. A supply chain weakness in the production build path may outrank several easy code findings because compromise could affect every release.

Score a candidate issue using four decisions:

1. Exploitable path: Is the weakness reachable from the internet, a partner, a low-privilege account, a build identity, or another plausible attacker position?
2. Business consequence: Could exploitation expose regulated or sensitive data, cross tenant boundaries, change money or identity, interrupt a critical service, or compromise every downstream release?
3. Control gap: Is the root control missing, inconsistently enforced, or dependent on a fragile workaround? Are meaningful preventive or detective controls actually operating?
4. Evidence confidence: Is the conclusion supported by a reproducible test and saved state, or only by a configuration claim, scanner label, or design assumption?

Use those decisions to create a short queue with an owner, deadline, test, evidence requirement, and exception path. For disclosed vulnerabilities in components, combine the application context with current severity, exploitation, and exposure evidence rather than treating a single score as the answer. The CVSS, EPSS, and CISA KEV prioritization guide explains that related operating decision.

A seven-step fix-first workflow

1. Scope one application. Record its users, roles, critical transactions, sensitive data, environments, public endpoints, internal services, third parties, and administrative paths. Draw trust boundaries and name the business owner.
2. Gather real evidence. Collect architecture and data-flow diagrams, authorization policy, deployed configuration, dependency and SBOM records, pipeline identities, secrets handling, code-review evidence, test results, logging routes, recent incidents, and accepted exceptions. Mark anything inferred rather than observed.
3. Rate exposure and consequence. Trace realistic attacker paths to critical actions and data. Consider preconditions, privileges, reachability, tenant boundaries, blast radius, recoverability, and the reliability of existing controls.
4. Select verifiable requirements. OWASP says the Top 10 is primarily an awareness document and a bare-minimum starting point. Use the OWASP Application Security Verification Standard to assign versioned, testable requirements. Record the ASVS version because requirement identifiers can change.
5. Fix the root cause. Prefer a reusable control—central authorization, secure defaults, parameterized interfaces, supported cryptography, hardened build paths, or safe transaction handling—over one-off filtering. Pair code changes with configuration, pipeline, identity, and operational changes when the weakness spans layers. Use the secure coding overview as foundational context, then make the requirement specific to this application and stack.
6. Retest the negative path. Reproduce the original condition and adjacent abuse cases. Confirm the prohibited action fails, authorized behavior still works, rollback is complete, sensitive details stay protected, and regression tests preserve the result.
7. Read back and operate. Verify the saved deployment state, not just a successful job. Generate safe test events, confirm logs and alerts, identify the response owner, store evidence, document residual risk, and schedule regression checks after material change.

This workflow aligns the Top 10 with a secure development lifecycle. NIST SP 800-218, the Secure Software Development Framework, provides a common set of high-level practices that organizations can integrate into existing development processes. OWASP’s AppSec program guidance adds threat modeling, secure code review, software composition analysis, secrets and infrastructure-as-code scanning, abuse cases, dynamic testing, and risk-appropriate penetration testing. Choose controls and tests based on the system rather than buying every tool category.

Evidence that a fix actually worked

Evidence layer	Useful proof	Weak substitute
Design	Updated threat model, trust boundary, abuse case, and approved control decision	“Security reviewed” in a ticket
Code	Focused review, test case, and versioned change tied to the requirement	A scanner issue marked resolved without reproduction
Configuration	Read-back of deployed policy, permissions, defaults, and network controls	A deployment-success message
Supply chain	Dependency inventory, provenance, protected promotion, reproducible artifact, and update test	An SBOM file that is never reconciled to production
Runtime	Safe negative-path test plus expected denial, rollback, log, alert, and response record	A log statement that nobody receives
Governance	Named owner, due date, accepted residual risk, exception expiry, and regression cadence	An unowned backlog entry

Common failure modes

Buying “full Top 10 coverage”

OWASP explicitly discourages claims of complete Top 10 coverage by a tool. Scanners can identify valuable subsets, but they cannot fully assess insecure design, business logic, effective operational alerting, or incident response. Ask vendors to map precise checks, versions, prerequisites, and blind spots instead.

Counting findings instead of closing paths

A team can close many low-impact findings while one cross-tenant authorization flaw remains reachable. Report the critical attack paths closed, controls implemented, tests passed, exceptions remaining, and operating evidence collected—not only ticket totals.

Testing only the happy path

Exceptional conditions, authorization bypasses, and workflow abuse appear when state is missing, duplicated, reordered, interrupted, or unauthorized. Make negative tests part of feature acceptance and regression, not a separate annual exercise.

Stopping at source code

A correct code change can be neutralized by an old deployment, permissive configuration, exposed administrative route, compromised pipeline, missing alert, or unsupported dependency. The saved runtime and delivery path are part of the security result.

Using the category name as the remediation

“Fix A01” is not executable. Name the application behavior, denied policy, root cause, owner, requirement, test, evidence, and release. A category organizes attention; it does not replace engineering detail.

Decision

Adopt the OWASP Top 10:2025 as a change detector and communication layer. Use it to ask whether your program now covers supply chain systems, server-side request authorization, exceptional conditions, and actionable alerting. Then leave the global ranking behind: scope one application, trace its highest-consequence paths, map them to versioned ASVS requirements, fix the root causes, and verify the deployed and operating evidence.

The first useful deliverable is not a “Top 10 compliant” badge. It is a short, owned remediation queue in which every item states what can go wrong, why it matters here, what will change, how the team will test it, and what evidence will prove it remains fixed.

Primary references

• OWASP Top 10:2025 Introduction
• OWASP: Establishing a Modern Application Security Program
• OWASP Application Security Verification Standard
• NIST SP 800-218: Secure Software Development Framework Version 1.1