OWASP Top 10:2025 Explained—What Changed and What to Fix First

The OWASP Top 10:2025 is a security-awareness document about major risks to web applications. It is not a complete testing standard, a compliance certificate, or a ranking of individual vulnerabilities.

The 2025 release analyzes 248 Common Weakness Enumerations across ten categories. It introduces two categories and consolidates others, reflecting a shift toward systemic failures: supply chains, insecure defaults, incomplete error handling, and controls that fail at architectural boundaries.^[1]

The 2025 list

1. A01 Broken Access Control
2. A02 Security Misconfiguration
3. A03 Software Supply Chain Failures
4. A04 Cryptographic Failures
5. A05 Injection
6. A06 Insecure Design
7. A07 Authentication Failures
8. A08 Software or Data Integrity Failures
9. A09 Security Logging and Alerting Failures
10. A10 Mishandling of Exceptional Conditions^[2]

A01: Broken Access Control

Access control decides which authenticated or unauthenticated actor may perform an action on a resource. Failures include cross-user data access, missing server-side role checks, path traversal, permissive cross-origin policy, and exposure of administrative functions.

The central fix is not unpredictable URLs. Enforce authorization on the server for every request and every object. Deny by default. Centralize policy where practical and test it with multiple users and roles.

Practical test:

1. User A creates Object A.
2. User B creates Object B.
3. Replay A's read, update, and delete requests as B.
4. Repeat across UI, API, alternate HTTP methods, and bulk functions.

A02: Security Misconfiguration

Misconfiguration covers insecure defaults, unnecessary services, verbose errors, missing hardening, inconsistent cloud permissions, and security headers or platform settings that do not match intended policy.

Configuration must be versioned, reviewed, tested, and monitored like code. A hardened image is not enough if deployment-time variables reopen access.

A03: Software Supply Chain Failures

This new category broadens the old focus on vulnerable and outdated components. Modern software depends on package registries, build systems, actions, plugins, containers, signing keys, and deployment pipelines. A failure anywhere in that chain can alter what reaches production.

Priorities include:

• inventory dependencies and build inputs;
• pin and verify critical artifacts;
• protect CI/CD identities and secrets;
• review maintainer and publication permissions;
• generate and use software bills of materials where useful;
• create an emergency process for compromised dependencies.

Updating packages is necessary, but supply-chain security also asks whether the update source and build process can be trusted.

A04: Cryptographic Failures

Cryptographic failures expose data because encryption is absent, algorithms or modes are unsuitable, keys are mishandled, randomness is weak, or transport protection is incomplete.

Begin with data classification and threat modeling. Use modern, reviewed libraries and protocols. Keep keys separate from protected data, rotate them through a planned lifecycle, and avoid designing custom cryptography.

A05: Injection

Injection occurs when untrusted data is interpreted as part of a command or query. SQL, operating-system commands, LDAP, expressions, and browser script are different contexts, but the engineering lesson is consistent: keep data separate from instructions.

Use parameterized APIs, contextual output encoding, constrained interpreters, and allowlists for the small number of elements—such as sort fields—that cannot be parameterized.

# Parameterized SQL: data remains data.
cursor.execute("SELECT * FROM orders WHERE id = %s", (order_id,))

A06: Insecure Design

Insecure design describes missing or ineffective controls at the design level. Perfect implementation cannot save a password-reset workflow that relies on public personal information or a ticketing system that allows unlimited reservation holds.

Use threat modeling, abuse cases, secure design patterns, and tests for business invariants. Ask how the feature could be misused by a valid user, not only how malformed input might break it.

A07: Authentication Failures

Authentication failures let attackers impersonate users through weak recovery, credential stuffing, session mistakes, missing rate controls, or poorly protected factors.

Use phishing-resistant authentication where possible, protect recovery as strongly as normal login, rotate session identifiers after authentication, check breached-password lists, and monitor unusual authentication behavior without creating easy account-lockout attacks.

A08: Software or Data Integrity Failures

Integrity failures occur when code, updates, serialized objects, or critical data are trusted without sufficient verification. This category includes unsafe deserialization and update mechanisms that lack signatures or provenance checks.

Define which components may produce trusted artifacts. Verify signatures and provenance, restrict deserialization formats, and separate untrusted processing from privileged execution.

A09: Security Logging and Alerting Failures

Logs are not a defense if no one can use them. Applications should produce events that support investigation: authentication changes, authorization failures, privileged actions, sensitive exports, security-control changes, and high-risk validation failures.

Protect log integrity, synchronize time, avoid recording secrets, define alert ownership, and test whether a real person receives enough context to act.

A10: Mishandling of Exceptional Conditions

This new category recognizes that systems often fail insecurely when assumptions break: errors are swallowed, transactions partially complete, resources are exhausted, or a fallback bypasses the normal control.

Design explicit failure states. Roll back transactions safely. Apply timeouts and resource limits. Return minimal errors to users while retaining diagnostic context internally. Test dependencies that are slow, unavailable, malformed, or inconsistent.

What changed in practical terms

The 2025 list puts more weight on the machinery around application code. A team can write parameterized queries and still be compromised through a build token, unsafe default, fragile recovery flow, or failure path.

That means the remediation owner is not always an application developer. Platform engineering, identity, procurement, product design, and incident response all own part of the list.

How not to use the OWASP Top 10

Do not use ten headings as the entire security program. The list groups common risks for awareness; it does not cover every technology, business workflow, or threat. OWASP’s Web Security Testing Guide provides broader test coverage across information gathering, identity, authentication, authorization, sessions, input validation, business logic, client-side behavior, and APIs.^[3]

Do not declare an application “OWASP compliant” because a scanner produced no Top 10 findings. Many access-control and business-logic failures require stateful, role-aware testing.

What to fix first

Prioritize real attack paths, not list order alone:

1. Externally reachable failures with direct access to sensitive actions or data.
2. Identity and access-control flaws that cross tenants or privilege levels.
3. Supply-chain and administration paths with broad blast radius.
4. Weaknesses already being exploited or exposed by known incidents.
5. Systemic root causes that remove many individual findings.

The best result of reading the OWASP Top 10 is not a checklist. It is a better set of engineering questions.

Sources