OWASP Top 10 2025 for Developers

The OWASP Top 10 is the list developers, testers and auditors reach for first when they talk about web application security. Published by the OWASP Foundation, it ranks the ten most critical categories of web application security risk, based on data from millions of tested applications and a survey of practitioners. The 2025 edition, released in November 2025, is the eighth.

It is not a law and not a certifiable standard. OWASP describes it as an awareness document. But it shows up everywhere compliance meets code: in secure coding policies, in PCI DSS requirement 6, in penetration test reports, in customer security questionnaires and in contracts that say an application must be "free of OWASP Top 10 vulnerabilities". This guide explains each 2025 category with practical prevention advice, what changed from 2021, and how to use the list properly alongside the OWASP ASVS.

What is the OWASP Top 10?

OWASP, the Open Worldwide Application Security Project, is a non-profit foundation that produces free application security resources. The Top 10 is its flagship document: a ranked list of categories of weaknesses, each mapped to entries in MITRE's Common Weakness Enumeration (CWE), with descriptions, example attack scenarios, prevention guidance and references.

The Top 10 is about categories, not individual bugs. "Injection", for example, includes SQL injection, OS command injection and cross-site scripting. Each category groups related CWEs, which is why the list is useful for awareness and reporting but too coarse to test against directly. For testable requirements, OWASP publishes the Application Security Verification Standard.

History and why it was created

The first OWASP Top 10 was published in 2003, and new editions followed in 2004, 2007, 2010, 2013, 2017, 2021 and 2025. Early editions were based mainly on expert opinion; later editions use data contributed by security vendors, consultancies and bug bounty platforms, plus a community survey to capture risks that testing data under-represents.

It was created because developers were repeating the same mistakes and had no simple, shared reference to learn from. A short ranked list was easy to teach, easy to put in a policy and easy to discuss with management. That simplicity is also why it became a de facto requirement in contracts, even though OWASP intended it to raise awareness rather than to serve as a compliance standard.

How the 2025 list was built

According to OWASP, contributors including Accenture, Bugcrowd, Veracode, Sonar and Semgrep, plus anonymous donors, supplied data covering more than 2.8 million applications. The data measured how many applications had at least one instance of each CWE, not how many instances. The dataset covered 589 CWEs; the ten categories contain 248 of them. Eight categories come from the data and two were promoted from the community survey: software supply chain failures and security logging and alerting failures. Exploit and impact scores were derived from CVE data mapped to CWEs.

Who should use the OWASP Top 10?

Developers building web applications and APIs in any language or framework.
Software companies and agencies that need a baseline for secure coding training and code review.
QA and security testers structuring test plans and reports.
Buyers of software writing security requirements into contracts and RFPs.
Compliance teams: PCI DSS requirement 6.2.4 expects software engineering techniques that prevent or mitigate common attacks, and assessors commonly use the OWASP Top 10 as a reference; ISO/IEC 27001 control 8.28 on secure coding is often implemented with it.

The list applies worldwide and to every industry. It has no legal force on its own.

The OWASP Top 10:2025 explained

A01:2025 Broken Access Control

Users can act outside their intended permissions: viewing another customer's records by changing an ID in the URL (insecure direct object references), calling admin APIs as a normal user, bypassing checks by modifying JWTs or cookies, or abusing CORS. In 2025, server-side request forgery (SSRF) was folded into this category. Prevent it by denying by default, enforcing authorisation on the server for every request (not just hiding buttons), checking record ownership in queries, using a central authorisation layer, rate-limiting APIs, logging access control failures, and blocking outbound requests to internal addresses where user input controls a URL.

A02:2025 Security Misconfiguration

Moved up from fifth. Default accounts, unnecessary features enabled, verbose error pages, missing security headers, open cloud storage buckets, debug mode in production, and XML parsers with external entities enabled. Prevent it with a repeatable hardening process, infrastructure as code reviewed like application code, minimal platforms, automated configuration scanning, and identical security settings across environments.

A03:2025 Software Supply Chain Failures

New in 2025, expanding the old "Vulnerable and Outdated Components". It covers compromised or vulnerable dependencies, malicious packages, weaknesses in build systems and CI/CD pipelines, and unverified updates. Prevent it with a software bill of materials (SBOM), dependency scanning and update policies, lock files, pinned versions with integrity checks, trusted registries, protected build pipelines with least privilege, signed artifacts and provenance as described in SLSA.

A04:2025 Cryptographic Failures

Sensitive data exposed through missing or weak cryptography: plain HTTP, outdated TLS, weak or unsalted password hashing, hard-coded keys, predictable random numbers, or sensitive data stored in clear text. Prevent it by classifying data, encrypting sensitive data in transit and at rest, using current TLS, hashing passwords with adaptive algorithms such as Argon2, scrypt or bcrypt, managing keys in a dedicated service, and not storing data you do not need.

A05:2025 Injection

Untrusted data sent to an interpreter as part of a command or query: SQL, NoSQL, OS commands, LDAP, template engines, and cross-site scripting in browsers. Prevent it with parameterised queries or safe ORM methods, avoiding dynamic command construction, server-side input validation with allow-lists, context-aware output encoding, Content Security Policy, and static analysis in the pipeline.

A06:2025 Insecure Design

Weaknesses in design rather than implementation: missing rate limits on sensitive flows, business logic that can be abused, trust boundaries in the wrong place. A perfect implementation of an insecure design is still insecure. Prevent it with threat modelling for new features, secure design patterns, abuse cases in requirements, and design reviews, supported by a process such as OWASP SAMM.

A07:2025 Authentication Failures

Renamed from "Identification and Authentication Failures". Credential stuffing, weak or default passwords, poor password recovery, session IDs in URLs, sessions that do not expire, and missing multi-factor authentication. Prevent it with MFA, checks against known breached passwords, rate limiting and lockout with care, secure session management with regeneration on login, and well-tested identity libraries or providers instead of custom code.

A08:2025 Software or Data Integrity Failures

Code and infrastructure that do not protect against integrity violations: insecure deserialisation, auto-updates without signature checks, loading scripts from untrusted CDNs without integrity checks, and data that crosses trust boundaries without verification. Prevent it with digital signatures, Subresource Integrity for third-party scripts, avoiding deserialisation of untrusted data, and review of pipeline and configuration changes.

A09:2025 Security Logging and Alerting Failures

Renamed to emphasise alerting. Attacks go unnoticed because logins, failures and high-value transactions are not logged, logs are not monitored, or alerts never reach anyone. Prevent it by logging authentication, access control failures and server-side validation failures with enough context, protecting logs from tampering and injection, sending them to a central platform, alerting on suspicious patterns, and having an incident response plan. Regulations such as India's CERT-In Directions add their own log retention requirements.

A10:2025 Mishandling of Exceptional Conditions

New in 2025. Applications that handle errors and unusual conditions badly: failing open when a dependency is down, leaking stack traces and internal details, inconsistent states after partial failures, logic errors in edge cases, and resource exhaustion. Prevent it by failing closed for security decisions, handling exceptions centrally, returning generic error messages to users while logging details internally, using transactions to keep data consistent, setting timeouts and limits, and testing failure paths deliberately.

What changed from the 2021 edition

2025	Change from 2021
A01 Broken Access Control	Still first; now includes SSRF (previously A10:2021)
A02 Security Misconfiguration	Up from A05
A03 Software Supply Chain Failures	New; broadens A06:2021 Vulnerable and Outdated Components
A04 Cryptographic Failures	Down from A02
A05 Injection	Down from A03
A06 Insecure Design	Down from A04
A07 Authentication Failures	Same position; renamed
A08 Software or Data Integrity Failures	Same position
A09 Security Logging and Alerting Failures	Same position; renamed from Logging and Monitoring
A10 Mishandling of Exceptional Conditions	New

If your policies, training or contracts reference the 2021 edition, update them. Mapping is straightforward, but the two new categories need new tests and training.

How to apply the OWASP Top 10 step by step

Adopt it in policy: your secure development policy should name the current edition as the minimum set of risks every application must address.
Train developers at least annually, with examples in your own languages and frameworks.
Threat model new features against the categories, especially access control and insecure design.
Add automated checks: static analysis, dependency and container scanning, secrets scanning and infrastructure-as-code checks in the CI pipeline.
Use code review checklists based on the categories for changes touching authentication, authorisation, data access and error handling.
Test dynamically: dynamic scanning in staging and periodic penetration testing that reports findings by category.
Verify with ASVS: choose an ASVS level and turn its requirements into acceptance criteria.
Track and fix findings with severity-based timelines, and measure recurrence by category.

Documentation you will need

The Top 10 itself requires no documents. When it is referenced by a policy, contract or standard, auditors and customers typically ask for:

A secure development policy that references the current edition.
Developer training records.
Code review guidelines or checklists.
Threat models for significant features.
Static and dynamic scan results and penetration test reports, with remediation evidence.
Dependency inventory or SBOM and patch records.

Audits, testing and "OWASP compliance"

There is no OWASP certification, and OWASP does not endorse vendors or products. Claims that an application is "OWASP compliant" usually mean that a penetration test or scan found no issues in the Top 10 categories at a point in time. That is useful evidence but not a guarantee. When a customer asks for OWASP Top 10 compliance, offer a recent penetration test report organised by category, your secure development process, and ideally verification against an ASVS level, which gives a defined, testable scope.

Timeline and cost considerations

Adopting the Top 10 as a baseline is quick; reaching a state where your applications are consistently free of these weaknesses is a continuing practice. Cost drivers are developer training time, scanning tools, penetration tests, remediation effort, and the age and size of the codebase. Older applications built without central authorisation or parameterised queries often need structural changes, which take longer than fixing individual findings.

Benefits and the risk of ignoring it

Using the Top 10 gives teams a shared language, helps prioritise the risks most often exploited, makes security testing more consistent, and answers many customer questions. It also supports compliance with PCI DSS requirement 6, ISO/IEC 27001 secure coding controls and the secure development expectations in the NIST SSDF and the EU Cyber Resilience Act.

Ignoring it has no legal penalty by itself, but the weaknesses it lists are behind many data breaches, and a breach caused by a well-known weakness is hard to defend to customers, regulators and courts as reasonable security.

Common mistakes and challenges for IT companies

Treating it as a complete standard. It covers ten categories; use ASVS for full requirements.
Front-end only access control. Hiding a button is not authorisation.
Relying on a WAF to fix code. A firewall reduces exposure but does not remove the weakness.
Old policy references. Contracts and policies still naming the 2017 or 2021 editions.
Dependency updates without ownership. Supply chain risk needs someone responsible for updates and alerts.
Verbose errors in production. Stack traces and SQL errors help attackers and fall under A02 and A10.
Logging without alerting. Logs nobody reads do not detect attacks.

Best practices, tools and technologies

Use framework features that are secure by default: ORM query builders, templating with auto-escaping, CSRF protection and built-in authentication.
Centralise authorisation in policies or middleware and test it with automated tests for each role.
Run static analysis (SAST), software composition analysis (SCA), secrets scanning and dynamic testing (DAST) in CI.
Set security headers, a Content Security Policy and Subresource Integrity for third-party scripts.
Use the OWASP Cheat Sheet Series for language- and topic-specific guidance.
Generate an SBOM for every release and monitor it for new vulnerabilities.

Our developers apply these practices in web application and API projects and fix findings from client penetration tests.

How the OWASP Top 10 relates to other frameworks

Framework	Relationship
OWASP ASVS	Detailed, testable requirements in three levels. Use it to verify what the Top 10 raises awareness of.
OWASP SAMM	A maturity model for the development process that prevents these risks.
PCI DSS	Requirement 6 expects protection against common software attacks; the Top 10 is a common reference.
NIST SSDF	Secure development practices expected of US government software suppliers.
ISO/IEC 27001	Annex A controls 8.25 to 8.29 on secure development are often implemented with OWASP resources.
EU Cyber Resilience Act	Legal requirement for products to be delivered without known exploitable vulnerabilities, among others.

Real-world implementation examples

Many major breaches map to Top 10 categories: unpatched framework components (now part of supply chain failures), injection in web forms, misconfigured cloud storage exposing data, and broken access control in APIs that let attackers enumerate other users' records by changing an identifier. Public bug bounty reports regularly show broken access control as one of the most common and valuable findings, which is consistent with its first place.

An illustrative case for a Laravel SaaS application: a penetration test finds that an API endpoint returns invoices for any ID, regardless of tenant. The fix is not a single patch but a change in pattern: a global tenant scope on queries, policy classes for every resource, and automated tests that try to access another tenant's data for each endpoint. Re-testing finds no further access control issues, and the pattern becomes part of the code review checklist.

Next steps

Update policies, training and contracts to the 2025 edition.
Add the two new categories to your test plans and checklists.
Choose an ASVS level for each application and turn it into acceptance criteria.
Automate scanning in CI and schedule penetration tests.
Fix structural weaknesses, starting with access control.

Frequently asked questions

What is the latest OWASP Top 10?

The OWASP Top 10:2025, the eighth edition, released in November 2025. It replaced the 2021 edition.

Is the OWASP Top 10 a compliance standard?

No. OWASP describes it as an awareness document. It becomes a requirement only when a contract, policy or other standard references it. For testable requirements, use the OWASP ASVS.

What is number one in the OWASP Top 10 2025?

Broken Access Control, which remained in first place and now also includes server-side request forgery.

What are the new categories in 2025?

A03 Software Supply Chain Failures, which broadens the old vulnerable components category, and A10 Mishandling of Exceptional Conditions.

Can an application be OWASP certified?

No. OWASP does not certify applications or vendors. You can show evidence through penetration tests, scans and verification against ASVS.

Does PCI DSS require the OWASP Top 10?

PCI DSS requires software engineering techniques to prevent or mitigate common software attacks and references industry standards and best practices. The OWASP Top 10 is the most commonly used reference, but PCI DSS does not mandate it by name as the only option.

Is there an OWASP Top 10 for APIs?

Yes. OWASP publishes a separate API Security Top 10, which is useful for API-first products alongside the main list.

How often is the OWASP Top 10 updated?

Roughly every three to four years. Recent editions were 2017, 2021 and 2025.

Does a web application firewall protect against the OWASP Top 10?

A WAF can block some attacks, especially injection, but it cannot fix access control, design or business logic weaknesses. Fix the code and use a WAF as an additional layer.

Is cross-site scripting still in the Top 10?

Yes, as part of the Injection category.

Who should be trained on the OWASP Top 10?

Every developer, tester and technical lead working on web applications or APIs, ideally with examples in the team's own frameworks, at least once a year.

How is the OWASP Top 10 different from the CWE Top 25?

The CWE Top 25 lists individual weaknesses ranked by data. The OWASP Top 10 groups weaknesses into broader risk categories for awareness and includes community input.