The OWASP Top 10:2025 is the eighth edition of OWASP’s widely used awareness document for web application security. It is not a checklist that proves an application is secure, and it is not a list of ten individual bugs. It is better understood as a map of major risk families that helps developers, testers and security teams decide where to look first.
The 2025 edition matters because modern applications depend on much more than application code. Configuration, dependencies, build pipelines, identity systems, cloud services and failure handling can all become part of the attack surface. The new list reflects that broader view.
The OWASP Top 10:2025 at a glance
| Rank | Category | A useful security question |
|---|---|---|
| A01 | Broken Access Control | Can this user access or change something they do not own or administer? |
| A02 | Security Misconfiguration | Did an unsafe setting, default or exposed feature create the weakness? |
| A03 | Software Supply Chain Failures | Can a dependency, build system or distribution path undermine the application? |
| A04 | Cryptographic Failures | Is sensitive data protected with appropriate cryptography and key management? |
| A05 | Injection | Can untrusted data change the meaning of a command, query or rendered output? |
| A06 | Insecure Design | Was a necessary security control missing from the design itself? |
| A07 | Authentication Failures | Can an attacker be incorrectly accepted as a legitimate identity? |
| A08 | Software or Data Integrity Failures | Does the system trust code or data without adequately verifying integrity? |
| A09 | Security Logging and Alerting Failures | Would suspicious activity be recorded, detected and acted on? |
| A10 | Mishandling of Exceptional Conditions | Does the application fail safely when something unexpected happens? |
OWASP describes the Top 10 as a standard awareness document representing broad consensus about critical web application security risks. A team should use it to improve security thinking, while deeper verification should use requirements and testing appropriate to the actual system.
What changed from 2021?
Three structural changes stand out. Software Supply Chain Failures is now A03. It expands the older focus on vulnerable and outdated components into the wider ecosystem used to create and deliver software. Dependencies still matter, but so do source repositories, developer tooling, CI/CD, artifact repositories and update paths.
Mishandling of Exceptional Conditions is new at A10. It covers failures around abnormal conditions, including unsafe error handling, logical errors and systems that fail open rather than fail securely.
Server-Side Request Forgery (SSRF) is no longer a standalone Top 10 category. OWASP maps it into A01 Broken Access Control in the 2025 edition. Security Misconfiguration also moves to A02, while Cryptographic Failures and Injection move to A04 and A05. A lower rank does not make a category unimportant for a particular application.
Original control map for this article. The categories overlap in real systems, so effective application security uses several control layers rather than treating each category as an isolated box.
A01: Broken Access Control
Authentication asks who the user is. Authorization asks what that identity is allowed to do. Imagine an application exposes /api/invoices/4821. A logged-in customer changes 4821 to 4822 and receives another customer’s invoice because the server checks only that the requester is authenticated. The identifier is valid, but the authorization decision is missing.
The same principle applies to administrative endpoints, files, API methods and tenant boundaries. Hiding an admin button in the browser is not access control because a client can send requests directly. Enforcement belongs on trusted server-side paths, with deny-by-default rules and ownership or role checks where appropriate.
A02: Security Misconfiguration
Secure code can still run inside an insecure environment. A production server may expose sample applications, a storage service may have excessive sharing permissions, directory listing may reveal files, or detailed errors may disclose implementation details.
Modern systems have many configuration layers: cloud IAM, containers, reverse proxies, frameworks, databases, API gateways and third-party services. Make secure configuration repeatable. Define environments as code where practical, remove unnecessary features, separate credentials by environment, automate checks and include configuration review in change management.
A03: Software Supply Chain Failures
An application can be carefully written and still inherit risk from what it trusts. A project may install one direct library that brings many transitive dependencies, while a build pipeline automatically retrieves and packages them.
OWASP’s 2025 category looks beyond known vulnerable components. It includes dependencies, developer tools, repositories, build infrastructure and distribution. Useful controls include maintaining an SBOM, tracking direct and transitive dependencies, monitoring vulnerability information, hardening repositories and CI/CD, applying least privilege and protecting artifact integrity.
Dependency scanning is useful but incomplete. Teams should also ask whether a compromised part of the delivery chain could change what reaches production.
A04: Cryptographic Failures
Cryptography protects data only when the whole design is sound. Failures include missing encryption, weak algorithms, poor randomness, exposed keys, nonce misuse, insecure key storage and incorrect certificate validation.
Consider an application that encrypts customer records but stores the encryption key in the same public source repository. The algorithm may be strong, yet the protection collapses because key management is weak. Use established libraries and protocols, protect keys separately from protected data, rotate and scope credentials appropriately, and avoid inventing cryptographic schemes.
A05: Injection
Injection occurs when untrusted data is interpreted as part of a command or instruction rather than remaining data. A vulnerable SQL pattern might build a query by concatenating user input:
query = "SELECT * FROM users WHERE email = '" + email + "'"A safer design uses parameterized queries so the query structure and supplied value remain separate. The category is broader than SQL. The exact defense depends on the interpreter, including parameterization, context-aware output encoding, safe APIs and avoiding command construction from untrusted strings.
The general rule is simple: do not let untrusted input become executable syntax.
A06: Insecure Design
A developer can implement a design exactly as specified and still produce an unsafe system if a necessary control was never designed. Imagine a password-reset workflow that relies only on information easily discovered about the account holder. Perfectly written code cannot compensate for a recovery process that provides insufficient identity assurance.
This category pushes security into requirements and architecture. Threat modelling, abuse cases, trust boundaries, business limits and secure design patterns help teams ask what must never happen before code exists.
A07: Authentication Failures
Authentication failures let a system accept an incorrect or illegitimate identity as valid. Problems can appear in login, recovery, session handling, API authentication and credential validation.
Strong authentication involves more than password complexity. Use established identity and session mechanisms, protect recovery paths, support multi-factor authentication where appropriate, rate-limit abusive attempts, rotate session identifiers after authentication, invalidate sessions correctly, and validate token issuer, audience, purpose and scope.
A08: Software or Data Integrity Failures
A08 focuses on trusting software or data without sufficient integrity verification. Suppose an application downloads an update from a trusted location but never verifies that the update is authentic and unchanged. If the delivery path is compromised, modified code may execute.
Useful controls include signed artifacts and updates, integrity verification, restricting trusted sources, protecting CI/CD paths and avoiding unsafe deserialization of untrusted data. The deeper principle is to make trust explicit and verifiable.
A09: Security Logging and Alerting Failures
Prevention is never perfect. Applications also need to reveal suspicious activity. If an attacker performs hundreds of failed logins, repeated authorization failures and then a high-value account change, those events should not disappear into unrelated local logs. Systems need useful security events, protected audit trails, monitoring and alerting that can lead to action.
Logging everything is not the answer. Avoid unnecessarily recording secrets or sensitive data, and tune alerts so important signals are not buried in noise.
A10: Mishandling of Exceptional Conditions
Software constantly encounters missing parameters, failed dependencies, timeouts, unexpected values and partial operations. A security problem appears when those conditions are handled unsafely.
For example, a failed authorization service should not cause a sensitive operation to be allowed merely because the permission check could not complete. That is a fail-open design. The goal is predictable failure. Validate assumptions, define safe defaults, roll back sensitive transactions when they cannot complete safely, limit resources, and deliberately test negative paths.
How these risks combine in one application
Consider an online learning platform with students, instructors and administrators. A student login involves A07 controls. When that student requests an assignment, A01 determines whether the account can access that record. Database operations need A05 controls to keep supplied values separate from query syntax.
The platform runs in a cloud environment, so A02 covers deployment settings while A03 covers dependencies and the build pipeline. A04 concerns sensitive data and credentials. Before code was written, A06 should have identified roles, trust boundaries and abuse cases. A08 asks whether trusted artifacts and critical data are verified. A09 determines whether attacks become visible. A10 asks what happens when a dependency, permission check or transaction fails.
This is why fixing one category does not make an application secure. The categories describe different ways that trust can break.
A practical way to use the Top 10
- Requirements: identify sensitive assets, roles, trust boundaries and high-risk actions.
- Design: threat-model important workflows and decide where authorization, integrity, cryptographic and failure controls belong.
- Implementation: use safe framework features, parameterized interfaces, centralized authorization and established security libraries.
- Build and deployment: inventory dependencies, harden CI/CD, verify artifacts and automate configuration checks.
- Testing: include negative authorization tests, injection testing, authentication abuse cases, configuration review and failure-path testing.
- Operation: monitor security events, protect logs, tune alerts, patch dependencies and rehearse incident response.
For deeper assurance, the Top 10 should lead into detailed material such as the OWASP Application Security Verification Standard rather than becoming the final security requirement.
Common misunderstandings
“Passing an OWASP Top 10 scan means the application is secure.” No automated scan can fully assess design, business logic, authorization, supply-chain governance or operational response.
“A01 is always the biggest risk for every application.” The ranking describes the OWASP dataset and process. Your threat model may make another category more urgent.
“The Top 10 is only for penetration testers.” Developers, architects, DevOps teams and product owners influence many of these risks before a security test begins.
“If a risk moved down, we can care less about it.” Ranking changes do not remove the need to assess that risk in your own system.
Where to go next
The OWASP Top 10 is most useful when it changes engineering decisions. It should lead to server-side authorization instead of hidden buttons, reproducible hardening instead of manual configuration, verifiable build artifacts instead of blind trust, parameterized queries instead of string-built commands, and deliberate failure handling instead of hoping the happy path always works.
For broader context, see Cybersecurity vs Information Security and What Is AI Security?. A dedicated article on Broken Access Control will examine authorization failures in more depth.