OWASP Top 10 2025: Web Application Risks, Changes, and Controls

The OWASP Top 10 2025 is the eighth edition of OWASP’s awareness document for critical web application security risks. Broken access control remains first, while security misconfiguration moves to second. The edition adds Software Supply Chain Failures and Mishandling of Exceptional Conditions, and it changes several category boundaries from 2021.

OWASP calls the Top 10 a starting point for improving application security culture. It is not a compliance standard, secure coding specification, or complete list of weaknesses. The official 2025 introduction explains the data and survey process behind the ranking.

Teams should use the categories to prompt design, implementation, testing, and operational questions. Passing a scanner or finding no sample exploit does not prove that an application is free of a category, especially for access control, insecure design, supply chain, and failure handling.

Key Takeaways

• The 2025 list expands attention beyond code flaws to configuration, supply chains, design decisions, integrity, and failure behavior.
• Broken access control stays at A01 and now includes server-side request forgery within its mapped weaknesses.
• A category is a family of related weaknesses, so each one needs several controls and tests rather than a single product check.
• Use ASVS, threat modeling, code review, automated testing, and operational evidence to go deeper than Top 10 awareness.

What Changed in the OWASP Top 10 2025

The 2025 edition has two new categories and one consolidation. Software Supply Chain Failures expands the older Vulnerable and Outdated Components entry to include build systems, dependencies, distribution, and compromise across the software ecosystem. Mishandling of Exceptional Conditions adds failures caused by incorrect error handling, abnormal states, and fail-open behavior.

Server-Side Request Forgery no longer stands alone. OWASP maps it into Broken Access Control, while Identification and Authentication Failures becomes Authentication Failures. Security Misconfiguration rises from fifth to second, based on the contributed dataset and survey process.

These changes do not mean older risks disappeared. A changed label often reflects a wider root-cause grouping. Reports should name the edition and map concrete findings to CWEs or application behaviors instead of treating the A-number as the whole explanation.

OWASP Top 10 2025 Risks Explained

A01: Broken access control

Broken access control lets a caller act outside intended permissions. Examples include reaching another user’s record, changing an identifier, invoking an administrative function, modifying a protected field, bypassing workflow state, or forcing a server to access a restricted destination.

Enforce authorization on the server for every object and action. Use deny-by-default policy, minimize cross-origin access, protect object identifiers with ownership checks, and invalidate sessions or cached decisions after privilege changes. Tests should cover horizontal, vertical, tenant, property, function, and state-based access.

A02: Security misconfiguration

Applications inherit configuration from frameworks, cloud services, containers, identity systems, gateways, and infrastructure. Default accounts, verbose errors, unnecessary features, permissive headers, exposed storage, and inconsistent environment settings create exploitable paths without a code defect.

Define secure baselines in version control and compare deployed state with them. Remove unused services, patch platforms, standardize headers and errors, restrict administration, and scan public assets from outside the trusted network. Review configuration changes with the same care as source changes.

A03: Software supply chain failures

Supply chain failures include vulnerable or malicious dependencies, compromised build systems, unsafe package resolution, altered artifacts, and untrusted distribution. The expanded category recognizes that checking a component version is only one part of software provenance.

Inventory direct and transitive components, lock resolved versions, review new dependencies, protect source and build identities, isolate build workers, and sign artifacts. Verify provenance during deployment and prepare a response path that identifies every system containing a compromised component.

A04: Cryptographic failures

Cryptographic failures expose data because encryption is absent, algorithms or modes are unsuitable, keys are mishandled, certificates are not validated, or sensitive values remain in logs and caches. Cryptography can be mathematically sound while its surrounding key lifecycle fails.

Classify data and decide which states need confidentiality and integrity. Use current platform libraries, protect keys in managed storage, rotate them under a tested process, enforce transport security, and avoid inventing algorithms or protocols. Passwords need an adaptive password hashing function rather than reversible encryption.

A05: Injection

Injection occurs when untrusted data changes the meaning of a command or query. SQL, operating system commands, directory queries, templates, expressions, and browser content all have interpreters with different syntax and escaping rules.

Prefer parameterized APIs, fixed operations, contextual output encoding, and safe templating. Validate syntax and business constraints, but do not rely on a blocklist of attack strings. Test every path where data reaches an interpreter, including asynchronous jobs and values returned by upstream services.

A06: Insecure design

Insecure design describes missing or ineffective controls in the intended architecture. Code can implement a design perfectly and still allow unlimited recovery attempts, unsafe business transitions, or one account to approve its own high-impact action.

Threat model important flows before implementation and write misuse cases beside normal requirements. Define trust boundaries, security invariants, transaction limits, separation of duties, and safe failure states. Revisit the model as features and integrations change.

A07: Authentication failures

Authentication failures allow account takeover or session misuse through weak credentials, unsafe recovery, missing rate controls, predictable identifiers, token validation errors, or sessions that are not revoked. Multifactor authentication reduces several paths but does not repair every session flaw.

Use a mature identity service, protect enrollment and recovery, reject breached passwords where appropriate, and rotate sessions after authentication changes. Verify token issuer, signature, audience, expiry, and type. Monitor automated attempts and let users terminate active sessions.

A08: Software or data integrity failures

Integrity failures arise when applications trust code, updates, serialized data, plugins, or pipeline output without verifying origin and modification. Unsafe deserialization can also create objects or behavior that the application never intended to accept.

Use signed artifacts and update channels, restrict who can change pipeline definitions, and verify provenance before release. Accept narrow data schemas, avoid deserializing untrusted native objects, and protect integrity metadata and signing keys separately from the artifacts they validate.

A09: Security logging and alerting failures

Missing or unusable security events delay detection and investigation. Logging a generic error is insufficient if responders cannot identify the actor, target, decision, time, source, outcome, and related request without exposing secrets.

Define events from abuse cases and incident questions. Centralize and protect records, synchronize time, detect meaningful patterns, test alerts, and assign ownership for response. Logs must avoid passwords, tokens, private keys, and unnecessary personal data.

A10: Mishandling of exceptional conditions

Applications encounter timeouts, partial writes, unavailable dependencies, exhausted resources, invalid states, and unexpected input. If error paths skip authorization, expose internal details, duplicate a transaction, use an unsafe default, or continue with incomplete validation, the failure becomes a security issue.

Fail closed for security decisions, handle exceptions at appropriate boundaries, and return controlled errors. Use transactions and idempotency for state changes, limit retries, test dependency failures, and confirm that cleanup removes temporary access and sensitive data.

Turn Each Category Into Verifiable Work

A useful backlog item names the component, expected security behavior, and evidence. “Address A01” is too broad. “Reject a project update when the authenticated tenant does not own the project, with unit and API tests for cross-tenant identifiers” gives engineering and review a shared pass condition.

Map categories to lifecycle stages. Insecure design needs architecture work, supply chain controls span source through deployment, and logging failures require operational testing. Injection and access control need implementation checks, but they also benefit from framework choices and reusable policy components.

Track findings at the weakness level. Two issues mapped to A02 may involve unrelated owners and fixes, such as an exposed cloud bucket and verbose framework errors. The Top 10 label helps reporting, while the concrete condition drives remediation.

Testing Needs More Than a Vulnerability Scanner

Automated tools are effective for known component issues, insecure headers, exposed files, input fuzzing, and certain injection patterns. They struggle with intended authorization, business workflows, exceptional states, and architectural trust. Scanner coverage should be documented rather than assumed.

Combine static analysis, dependency and artifact checks, infrastructure review, dynamic testing, unit tests, and manual abuse cases. Add fault injection for timeouts, partial failures, and unavailable services. Review logs and alerts during testing to confirm that exploitation attempts create useful evidence.

Security regression tests should stay with the code. A fixed access-control bug can return through a new endpoint or alternate method, while a pipeline fix can be bypassed by a second release path. Tests tied to the specific failure make future review cheaper and clearer.

OWASP Top 10, ASVS, and Threat Modeling Have Different Jobs

The Top 10 raises awareness and provides broad categories. The OWASP Application Security Verification Standard provides a deeper catalog of requirements that can support verification. Threat modeling applies those concerns to a particular system, its assets, actors, boundaries, and business impact.

Use the Top 10 to start conversations and check coverage. Use ASVS to define testable application requirements, then use threat modeling to find risks created by the actual architecture and workflows. None of them removes the need to understand the system under review.

API-heavy applications should also use the OWASP API Security Top 10 guide. AI-enabled systems may need the LLM, agentic, MCP, and non-human identity lists because their components introduce additional failure modes.

Frequently Asked Questions

What is the latest OWASP Top 10 version?

The latest released web application edition is OWASP Top 10 2025. It follows the 2021 edition and changes several names, mappings, and rankings. Reports and policies should state the year instead of referring to an unspecified OWASP Top 10.

Is the OWASP Top 10 a security standard?

OWASP describes it as a standard awareness document, but it is not a complete verification standard. It groups major risk families and encourages organizations to improve application security practices. OWASP ASVS offers more detailed application security requirements.

Does compliance with the Top 10 mean an application is secure?

No, the list covers ten broad categories and cannot represent every architecture, business workflow, platform, or threat. An application can avoid known examples while retaining serious authorization or design flaws. Security claims need scoped testing evidence and an application-specific risk assessment.

Why did the OWASP Top 10 change in 2025?

OWASP used contributed data and a community survey to update category scope and ordering. The project added broader software supply chain coverage and a category for exceptional-condition handling. It also consolidated SSRF into Broken Access Control and renamed several categories.