OWASP Top 10

1. Introduction

The OWASP Top 10 is the single most widely referenced application security awareness document in the world. Published by the Open Worldwide Application Security Project (OWASP), a non-profit foundation dedicated to improving the security of software, it distils the most critical web application security risks into a consensus-driven, ranked list. For any organisation building, buying, or operating web applications and APIs, the OWASP Top 10 has become the de facto baseline against which secure development, penetration testing, and application security assurance programmes are measured.

This guide is written from the perspective of a CERT-In empanelled auditor and PCI Qualified Security Assessor (QSA). It is intended to help engineering leaders, application security teams, compliance officers, and internal audit functions understand not merely what the OWASP Top 10 lists, but how to operationalise it: how to scope an assessment, what evidence to demand, how to map findings to a maturity model, and how the Top 10 interlocks with binding regulatory frameworks such as PCI DSS, the DPDP Act, ISO/IEC 27001, and the CERT-In directions. Throughout, we treat the OWASP Top 10 not as a checklist to be ticked once, but as a living control set to be embedded across the secure software development lifecycle (SSDLC).

2. What is the OWASP Top 10

The OWASP Top 10 is a periodically updated, ranked list of the ten most critical security risks facing web applications. It is not a formal standard, a certification scheme, or a prescriptive control catalogue in the manner of ISO 27001 or PCI DSS. Instead, it is an awareness and prioritisation document: a shared vocabulary that lets developers, testers, and executives agree on which classes of vulnerability warrant the most urgent attention.

Each entry describes a category of risk rather than a single vulnerability. For example, the category A03:2021 - Injection encompasses SQL injection, NoSQL injection, OS command injection, LDAP injection, expression-language injection, and cross-site scripting (which OWASP folded into Injection in 2021). Categories are ranked using a blend of empirical data (contributed by dozens of security firms covering hundreds of thousands of applications) and an industry survey that captures emerging risks for which hard data may lag.

OWASP maintains parallel Top 10 lists for different technology domains, and it is important not to confuse them. The flagship list is the OWASP Top 10 for web applications. Sibling projects include the OWASP API Security Top 10, the OWASP Mobile Top 10, the OWASP Top 10 for Large Language Model Applications, the OWASP Top 10 CI/CD Security Risks, and the OWASP Top 10 Proactive Controls. Unless otherwise qualified, references in this guide are to the web application Top 10:2021 edition.

Crucially, the OWASP Top 10 is a floor, not a ceiling. Being free of Top 10 issues does not make an application secure; it means the most common and impactful risk classes have been addressed. Mature programmes pair the Top 10 with the broader OWASP Application Security Verification Standard (ASVS), the OWASP Testing Guide, and threat modelling to achieve defensible assurance.

3. Who must comply

Compliance with the OWASP Top 10 is rarely a direct legal mandate; rather, it is embedded by reference into contracts, regulatory guidance, and industry standards. In practice, any organisation that develops or operates internet-facing software is expected to demonstrate that its applications are free of Top 10-class defects. The following table identifies the principal audiences and the mechanism through which the Top 10 becomes binding on them.

4. Structure of the OWASP Top 10

The OWASP Top 10:2021 comprises ten ranked risk categories, each identified by an Axx code (A01 through A10). Every category aggregates one or more Common Weakness Enumeration (CWE) entries and carries data on incidence rate, exploitability, and impact. The table below enumerates the full 2021 list with its constituent themes and representative CWE mappings. Three categories were new or substantially restructured in 2021: A04 Insecure Design, A08 Software and Data Integrity Failures, and A10 Server-Side Request Forgery.

5. Master assessment checklist

This is the operational heart of the guide. For each of the ten categories we provide the concrete items an auditor should verify and the typical evidence that substantiates them. The intent is exhaustive coverage: every category is addressed with a dedicated table so that no risk class is skipped during an assessment. Verification items are drawn from the OWASP prevention guidance, the ASVS, and field audit practice.

A01 - Broken Access Control

A02 - Cryptographic Failures

A03 - Injection

A04 - Insecure Design

A05 - Security Misconfiguration

A06 - Vulnerable and Outdated Components

A07 - Identification and Authentication Failures

A08 - Software and Data Integrity Failures

A09 - Security Logging and Monitoring Failures

A10 - Server-Side Request Forgery (SSRF)

6. Scoping

Effective scoping determines whether an OWASP Top 10 assessment produces defensible assurance or a false sense of security. Because the Top 10 is application-centric, scope should be expressed in terms of applications, APIs, and the environments in which they run, not merely IP ranges. Before testing begins, agree the boundary in writing.

• Enumerate every in-scope application, micro-service, and API, including internal and partner-facing interfaces.
• Identify the environments to be tested (production, staging, or a production-parity test environment) and confirm data handling rules.
• Decide which Top 10 edition and companion standards apply (web Top 10:2021, API Security Top 10, ASVS level).
• Determine test perspectives: unauthenticated, authenticated per role, and multi-tenant cross-account testing.
• Confirm authentication material, test accounts, and API keys required for authenticated coverage.
• Clarify exclusions (third-party SaaS, DoS testing, social engineering) and rules of engagement, including test windows.
• Include supporting infrastructure and configuration only insofar as it affects application risk (TLS, WAF, cloud storage).
• Define the definition-of-done for remediation and retesting before the engagement starts.

7. Implementation approach

Embedding the OWASP Top 10 into an organisation is a programme, not a project. The following phased approach moves from baseline awareness to continuous, automated assurance across the SSDLC. Each phase lists indicative activities and the deliverables that evidence its completion.

Phase 1 - Baseline and awareness

• Activities: Establish a secure-coding standard mapped to the Top 10; deliver developer awareness training; perform a gap assessment of current applications against each category.
• Deliverables: Secure-coding standard, training completion records, baseline gap-assessment report and risk register.

Phase 2 - Tooling and pipeline integration

• Activities: Integrate SAST, DAST, SCA, and secret scanning into CI/CD; define quality gates by severity; produce an SBOM for each build.
• Deliverables: Pipeline configuration with security gates, tool coverage matrix, SBOM artefacts, initial scan baselines.

Phase 3 - Secure design and threat modelling

• Activities: Introduce threat modelling for new features; establish an architecture review gate; build a library of reusable secure design patterns (addressing A04).
• Deliverables: Threat-model templates and completed models, design review checklist, secure design pattern catalogue.

Phase 4 - Verification and penetration testing

• Activities: Conduct manual penetration testing aligned to the OWASP Testing Guide and ASVS; verify business-logic and access-control risks that tools miss; perform remediation and retesting.
• Deliverables: Penetration test reports, remediation tracker, retest confirmation, ASVS verification results.

Phase 5 - Continuous assurance and governance

• Activities: Operationalise logging and monitoring (A09); run continuous component monitoring; maintain metrics and executive reporting; feed findings back into standards and training.
• Deliverables: Security metrics dashboard, monitoring and alerting coverage report, periodic management review records, updated standards.

8. Maturity and capability model

To move beyond pass/fail thinking, organisations should assess the maturity of their OWASP Top 10 programme. The model below draws on the spirit of OWASP SAMM (Software Assurance Maturity Model) and provides five levels against which capability can be scored. Each application or business unit can be rated, and the aggregate reveals where investment is needed.

9. Assessment and audit approach

A structured audit ensures the OWASP Top 10 is genuinely embedded rather than merely claimed. The following ordered steps describe how CyberSigma conducts an OWASP-aligned application security assessment.

1. Define scope, rules of engagement, and success criteria with stakeholders, and confirm the applicable Top 10 edition and ASVS level.
2. Gather documentation: architecture diagrams, data-flow diagrams, threat models, secure-coding standards, and prior test reports.
3. Perform reconnaissance and mapping of the application, its endpoints, roles, and trust boundaries.
4. Run automated testing (SAST, DAST, SCA, secret scanning) to establish a coverage baseline and surface obvious defects.
5. Conduct manual testing against each of the ten categories, prioritising access control, injection, and business-logic abuse.
6. Perform authenticated and multi-role testing to expose broken access control and privilege escalation.
7. Validate findings to eliminate false positives and confirm real-world exploitability and impact.
8. Rate each finding by severity using CVSS and business context, and map it to the relevant Top 10 category and CWE.
9. Deliver a prioritised report with reproduction steps, evidence, and remediation guidance.
10. Support remediation, then retest to confirm closure and update the risk register and maturity rating.

10. Evidence request list

The following categorised evidence supports an OWASP Top 10 assessment. Requesting it in advance accelerates the engagement and demonstrates programme maturity to auditors and customers.

• Governance and policy: secure-coding standard, application security policy, SSDLC procedure, patch-management policy.
• Design artefacts: architecture and data-flow diagrams, threat models, security requirements register, design review sign-offs.
• Access control: RBAC/authorisation matrix, CORS configuration, session-management design.
• Cryptography: data classification register, TLS configuration and scan reports, key-management and rotation policy.
• Components and supply chain: SBOM, SCA scan reports, dependency lock files, EOL component register.
• Authentication: MFA policy and enrolment reports, password policy, identity-provider configuration.
• Pipeline and integrity: CI/CD configuration with security gates, artefact-signing and provenance evidence, secret-scan output.
• Configuration: hardening baselines and compliance scans, CSPM reports, security-header captures.
• Logging and monitoring: logging standard, SIEM alert rules, sample log records, incident-response plan and test records.
• Testing history: prior penetration test reports, remediation trackers, retest confirmations, vulnerability metrics.

11. Roles and responsibilities

Clear ownership prevents OWASP Top 10 controls from falling between teams. The table below assigns primary responsibilities across the typical operating model.

12. KPIs to track

Metrics turn the OWASP Top 10 from an aspiration into a managed capability. Track the following indicators and trend them over time.

• Percentage of applications with Top 10 coverage in the CI/CD pipeline (SAST/DAST/SCA).
• Number of open findings by Top 10 category and severity.
• Mean time to remediate (MTTR) critical and high findings against SLA.
• Percentage of releases passing security gates without exception.
• Percentage of new features with a completed threat model (A04 coverage).
• Number of vulnerable or end-of-life components in production (A06).
• Percentage of sensitive endpoints protected by MFA (A07).
• Security event logging and alert coverage against target scenarios (A09).
• Recurrence rate of previously remediated defect classes.
• Penetration test findings closed and retested per cycle.

13. Readiness checklist

• A secure-coding standard mapped to the OWASP Top 10 is documented and adopted.
• SAST, DAST, SCA, and secret scanning run in the CI/CD pipeline with severity-based gates.
• An up-to-date SBOM exists for every production application.
• Deny-by-default access control is enforced server-side and tested for IDOR and privilege escalation.
• All data in transit uses TLS 1.2+ and sensitive data at rest is encrypted with current algorithms.
• Parameterised queries and context-aware output encoding are used throughout (injection and XSS).
• Threat modelling is performed for new features and significant changes.
• MFA is enforced for administrative and sensitive access, with anti-brute-force protections.
• Security-relevant events are logged, centralised, and alerted via a SIEM.
• CI/CD pipelines and dependencies are integrity-protected against supply-chain tampering.
• Server-side fetches validate URLs and block internal and cloud-metadata addresses (SSRF).
• Penetration testing aligned to the OWASP Testing Guide is performed at least annually and after major change.

14. Common gaps

Across hundreds of assessments, the same weaknesses recur. Anticipating them accelerates remediation.

• Access control enforced in the UI but not the API, leaving IDOR and forced-browsing exposures.
• Reliance on automated scanning alone, missing business-logic and multi-tenant access-control flaws.
• Sensitive data logged in plaintext or exposed via verbose error messages.
• Outdated components in production with no SBOM or patch SLA, especially transitive dependencies.
• MFA available but not enforced for all privileged accounts, and weak session-management defaults.
• Threat modelling treated as documentation theatre rather than driving design decisions (A04).
• Security headers and hardening baselines missing or inconsistent across environments.
• Insufficient logging of access-control failures, leaving breaches undetectable (A09).
• CI/CD pipelines with weak access control and unsigned artefacts, enabling supply-chain compromise.
• SSRF protections absent on features that fetch remote URLs, exposing cloud metadata endpoints.

15. OWASP Top 10 mapped to other frameworks

The Top 10 rarely operates in isolation. The table below maps each category to related obligations in PCI DSS v4.0, ISO/IEC 27001:2022 Annex A, the NIST Cybersecurity Framework, and India's DPDP Act reasonable-security expectations, helping teams demonstrate coverage across multiple audits from a single body of work.

Frequently asked questions

Need help with OWASP Top 10?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.