OWASP Top 10:2025 Explained for Development Teams

Most data breaches in web applications come from a familiar set of weaknesses: broken access control, misconfiguration, vulnerable dependencies, injection and weak authentication. The OWASP Top 10 lists these risks and is referenced by client security questionnaires, penetration testing scopes and secure development policies worldwide. The OWASP Top 10:2025 edition added software supply chain failures and the mishandling of exceptional conditions. This guide explains each risk, how development teams can prevent it, and how to use the Top 10 in a secure development programme without mistaking it for a complete standard.

What is the OWASP Top 10?

The OWASP Top 10 is a ranked list of the most critical security risk categories for web applications, based on data contributed by security firms and a community survey. Each category groups related weaknesses (CWEs) and comes with descriptions, examples and prevention guidance.

Full form and definition

OWASP stands for the Open Worldwide Application Security Project (formerly the Open Web Application Security Project). It is run by the OWASP Foundation, a non-profit that produces free tools, documentation and standards for software security.

Law, standard or certification?

The Top 10 is an awareness document. OWASP itself recommends it as a starting point, not as a standard to certify against. Contracts, PCI DSS assessments and client policies often require that applications be tested for "OWASP Top 10" risks, which makes it contractually important.

History and background

OWASP was founded in 2001 and released the first Top 10 in 2003, followed by editions in 2004, 2007, 2010, 2013, 2017, 2021 and 2025. Over time the list has moved from specific bugs (such as cross-site scripting as its own category) to broader root causes such as insecure design and supply chain failures.

What changed in the 2025 edition?

• Software Supply Chain Failures (A03) is new, expanding the 2021 "Vulnerable and Outdated Components" category to the whole build and dependency chain.
• Mishandling of Exceptional Conditions (A10) is new, covering improper error handling, failing open and logic errors in abnormal conditions.
• Security Misconfiguration rose to second place.
• Server-Side Request Forgery, a separate category in 2021, was merged into Broken Access Control.
• Categories were renamed for clarity, for example "Authentication Failures" and "Logging and Alerting Failures".

Why was the OWASP Top 10 introduced?

Developers and managers needed a short, shared list of the most important web application risks to raise awareness and prioritise effort, at a time when application security knowledge was concentrated among specialists.

Main objectives and purpose

• Raise awareness of the most critical web application security risks.
• Give developers, testers and managers a common vocabulary.
• Point teams to prevention techniques and deeper OWASP resources.
• Provide a baseline for training and testing scopes.

Who needs the OWASP Top 10?

• Software development companies and agencies building web and mobile back ends
• SaaS product teams
• QA and penetration testing teams
• Organisations subject to PCI DSS, client security reviews or SOC 2 and ISO 27001 audits that ask about secure development
• Indian IT services companies whose clients require OWASP-based testing before go-live

The Top 10 is used worldwide and is not tied to any jurisdiction.

The OWASP Top 10:2025 risks and how to prevent them

A01: Broken Access Control

Users can act outside their intended permissions: viewing other users' records by changing an ID (insecure direct object references), accessing admin functions, or making the server fetch internal resources (SSRF). Prevent by denying by default, enforcing authorisation on the server for every request, checking object ownership, and restricting outbound requests from servers.

A02: Security Misconfiguration

Default credentials, verbose errors, open cloud storage, unnecessary features enabled, missing security headers. Prevent with hardened, repeatable configurations, infrastructure as code, configuration scanning and minimal platforms.

A03: Software Supply Chain Failures

Vulnerable or malicious dependencies, compromised build tools or pipelines, unverified packages and unpatched components. Prevent with a software bill of materials (SBOM), dependency scanning, pinned and verified packages, protected CI/CD pipelines and timely updates.

A04: Cryptographic Failures

Sensitive data sent or stored without strong encryption, weak algorithms, poor key management or predictable randomness. Prevent by classifying data, using TLS everywhere, modern algorithms and managed key services, and hashing passwords with adaptive functions such as Argon2 or bcrypt.

A05: Injection

Untrusted input interpreted as code or commands, including SQL, NoSQL, OS command and LDAP injection, and cross-site scripting. Prevent with parameterised queries, safe APIs, context-aware output encoding, input validation and content security policies.

A06: Insecure Design

Flaws in the design itself, such as missing rate limits on sensitive functions or business logic that can be abused. Prevent with threat modelling, secure design patterns, abuse case testing and security requirements in user stories.

A07: Authentication Failures

Credential stuffing, weak passwords, broken session management and missing MFA. Prevent with MFA, breached password checks, rate limiting, secure session handling and well-tested identity libraries or providers.

A08: Software or Data Integrity Failures

Code or data trusted without integrity verification, such as unsigned updates, insecure deserialisation or untrusted CDN scripts. Prevent with digital signatures, integrity checks, subresource integrity and safe deserialisation practices.

A09: Logging and Alerting Failures

Attacks go unnoticed because events are not logged, logs are not monitored, or alerts do not reach anyone. Prevent by logging security-relevant events with context, protecting logs, and setting up alerting and response.

A10: Mishandling of Exceptional Conditions

Applications that fail open, leak sensitive details in errors, or enter unsafe states when something unexpected happens. Prevent with consistent error handling, failing closed, resource limits and testing of edge cases and failure paths.

How to use the OWASP Top 10 in your development process: step by step

1. Train developers on the Top 10 with examples in your own languages and frameworks.
2. Add security requirements to user stories, using ASVS for detailed, testable requirements.
3. Threat model new features and significant changes.
4. Use secure defaults in frameworks and shared libraries for authentication, authorisation, encoding and crypto.
5. Automate testing in CI/CD: static analysis (SAST), dependency scanning (SCA), secrets scanning and dynamic testing (DAST).
6. Review code with a security checklist for high-risk changes.
7. Penetration test before major releases and at least annually, with the Top 10 as a minimum scope.
8. Fix by severity with agreed remediation timelines.
9. Monitor production with logging, alerting and a web application firewall where appropriate.
10. Measure recurring vulnerability types and target training accordingly.

Documentation that supports Top 10 coverage

• Secure development policy referencing OWASP guidance
• Security requirements or ASVS level for each application
• Threat models
• SAST, SCA and DAST reports and remediation records
• Penetration test reports and retest results
• SBOMs for released software
• Developer training records

Audit and assessment requirements

There is no OWASP certification for applications or companies. Assessment happens through penetration tests, code reviews and automated scanning. Clients usually ask for a recent third-party penetration test report showing Top 10 coverage and remediation. For deeper, verifiable assurance, use OWASP ASVS levels 1 to 3 as the test basis.

Estimated timeline

• Initial gap review and test of a typical web application: 2 to 4 weeks
• Integrating SAST, SCA and secrets scanning into CI/CD: 2 to 6 weeks
• Developer training programme: ongoing, with an initial round in 1 to 2 months

Cost considerations

• Penetration testing by qualified testers
• Application security tools (many free open-source options exist, including OWASP projects)
• Developer training time
• Remediation effort, which is lower when issues are found early

Benefits of addressing the OWASP Top 10

• Fewer exploitable vulnerabilities in production.
• Faster client security reviews and go-live approvals.
• Lower remediation cost by catching issues in development.
• Evidence for PCI DSS, SOC 2 and ISO 27001 secure development controls.

Risks of ignoring the Top 10

There are no direct penalties, but these risks are among the most common causes of breaches, which can trigger regulatory action under laws such as the GDPR or DPDP Act, contract claims and lost business.

Common mistakes

• Treating the Top 10 as a complete standard or a checklist to tick.
• Relying only on automated scanners, which miss access control and business logic flaws.
• Testing once before launch and never again.
• Ignoring APIs, mobile back ends and admin panels in test scope.
• Not tracking third-party and open-source components.

Challenges for IT companies

• Clients using different editions (2021 versus 2025) in requirements.
• Fast delivery schedules in fixed-price projects that squeeze security work.
• Legacy codebases with deep injection or access control issues.
• Supply chain risks from many open-source packages.

Best practices and recommendations

• Map your secure development policy to the 2025 edition and update test scopes.
• Use ASVS for requirements and the OWASP Web Security Testing Guide for testing methods.
• Build shared, reviewed components for authentication and authorisation.
• Generate SBOMs for every release.
• Combine with CIS Control 16 and NIST CSF for a programme view.

Tools and technologies that help

• SAST tools integrated into pull requests
• Software composition analysis and SBOM generators
• Secrets scanning
• DAST tools, including OWASP ZAP
• Web application firewalls and API gateways
• OWASP Dependency-Check and Dependency-Track

Relationship with other compliance frameworks

OWASP Top 10 and related frameworks

Framework	Relationship
PCI DSS	Requirement 6 expects protection against common software attacks; OWASP categories are widely used to show this
ISO 27001	Annex A secure development and testing controls
SOC 2	Change management and vulnerability management criteria
CIS Controls	Control 16, Application Software Security
NIST CSF	Protect function outcomes for platform security and secure development

Real-world implementation examples

The following are illustrative composites based on common patterns, not named clients.

Development agency

An agency added SAST and dependency scanning to every client repository, created a reusable authorisation middleware, and began delivering a Top 10 test summary with each release. Its clients' pre-launch penetration tests stopped finding access control issues.

SaaS product team

A SaaS company updated its secure development policy to the 2025 edition, added SBOM generation and package signature checks to its pipeline, and set alerts on authentication anomalies.

Frequently asked questions

What is the latest OWASP Top 10?

OWASP Top 10:2025, which replaced the 2021 edition.

What is new in the OWASP Top 10:2025?

Two new categories, Software Supply Chain Failures and Mishandling of Exceptional Conditions, with SSRF merged into Broken Access Control and Security Misconfiguration moving up to second place.

Is the OWASP Top 10 a compliance standard?

No. It is an awareness document. Use OWASP ASVS for testable requirements.

Can a company be OWASP certified?

No. There is no OWASP certification for organisations or applications.

Does PCI DSS require the OWASP Top 10?

PCI DSS requires protection against common software attacks and vulnerabilities, and OWASP categories are a common way to demonstrate this, but PCI DSS does not mandate the Top 10 by name.

Is there an OWASP Top 10 for APIs?

Yes. OWASP publishes a separate API Security Top 10, as well as lists for mobile and large language model applications.

How often is the OWASP Top 10 updated?

Roughly every three to four years. Previous editions were 2017 and 2021.

Which is the number one OWASP risk?

Broken Access Control is A01 in both the 2021 and 2025 editions.

Is the OWASP Top 10 enough for secure development?

No. It covers the most common risks, but a complete programme also needs threat modelling, detailed requirements, testing and monitoring.

Conclusion and next steps

The OWASP Top 10 is the best-known starting point for application security. Use it to train teams and scope tests, then build a fuller secure development lifecycle with ASVS and automation.

1. Update your policies and test scopes to the 2025 edition.
2. Train developers on each category.
3. Automate SAST, SCA and secrets scanning.
4. Penetration test regularly and fix by severity.
5. Track supply chain risk with SBOMs.

How we keep this guide up to date

We review this guide every six months and whenever OWASP publishes a new Top 10 edition, related Top 10 lists or major updates to ASVS.