OWASP Top 10 2025: What VAPT Teams Must Test

The OWASP Top 10 has been the reference framework for web application security priorities since 2003. The 2025 revision, published after nearly four years of data collection, reshapes the list to reflect what practitioners actually observe in modern applications: authorization failures dominate, cryptographic issues have consolidated, and previously distinct categories have been merged where the boundary between them stopped being useful. This document describes how VAPT programmes should align to the new list.

What Changed in the 2025 Revision

The most substantial shift is the consolidation of injection categories. Previous editions listed injection variants separately at multiple positions; 2025 combines classical injection, template injection, and expression language injection into a single category, reflecting that modern applications frequently exhibit these issues at different layers and that the underlying developer-facing prevention guidance is largely shared. VAPT programmes should ensure their testing covers all injection surfaces, not just the SQL and NoSQL layers that received the most historical attention.

Server-Side Request Forgery (SSRF), previously a subordinate concern, is now elevated to its own top-level category. The elevation reflects the shift of application infrastructure into cloud environments where SSRF frequently escalates to metadata endpoint exploitation, cross-service authentication token theft, and lateral movement across cloud resources. VAPT scope for cloud-hosted applications should assume that any input that accepts a URL is a potential SSRF vector until proven otherwise.

The "Vulnerable and Outdated Components" category has been restructured to distinguish direct dependencies from transitive dependencies and to elevate supply chain compromise as a specific concern. This reflects the increase in software supply chain attacks over the last four years and the growing regulatory attention on Software Bills of Materials (SBOMs). VAPT reports should include the SBOM analysis alongside runtime testing findings.

Broken Access Control Remains at the Top

Broken Access Control has held the top position in the last two editions and remains at the top for 2025. This is not because access control is a new problem — it is because access control failures are pervasive, difficult to detect with automated tools, and consistently produce the highest-impact breaches. VAPT programmes that treat access control as a specialised concern rather than a first-class testing focus systematically underrepresent it in their findings.

Effective access control testing requires multi-account, multi-role, multi-tenant testing across every application endpoint. It is not sufficient to test a handful of representative endpoints with two user accounts; the systematic approach tests every endpoint with every combination of authenticated user, unauthenticated user, cross-tenant user, elevated role, and reduced role. This is where AI-augmented VAPT platforms provide meaningful lift over manual testing — the systematic enumeration that produces confident access control coverage is precisely the kind of high-volume mechanical work that automation excels at.

Access control findings are frequently under-severity-rated in reports because the finding text describes the technical issue ("endpoint X does not validate role membership") without quantifying the business impact ("endpoint X permits any authenticated user to read any customer's billing history"). Modern reporting practice pairs the technical finding with impact narrative and sanitised evidence to communicate risk in terms the business can act on.

Cryptographic Failures and Modern Implementations

The 2025 revision consolidates cryptographic issues under a single category that spans transport layer configuration, at-rest encryption, key management, and cryptographic primitive selection. This reflects the reality that cryptographic failures are rarely isolated — an application using deprecated TLS ciphers is typically also using questionable key management practices and outdated cryptographic primitives elsewhere in the codebase.

VAPT testing for cryptographic failures now extends to post-quantum readiness assessments in addition to the traditional TLS configuration audit. Regulators and standards bodies have begun explicitly encouraging assessment of the organisation's roadmap for migrating to quantum-resistant algorithms; VAPT reports that address this proactively are increasingly valued by security-mature organisations.

Modern cryptographic testing also considers the storage of cryptographic material — whether keys are in Hardware Security Modules (HSMs) or Key Management Services (KMS) versus stored in code or configuration, whether key rotation is enforced, and whether cryptographic operations use up-to-date library versions rather than deprecated wrappers. These implementation details rarely appear in vulnerability scanners but are central to the cryptographic controls that compliance frameworks require.

Insecure Design as a Distinct Category

The "Insecure Design" category, introduced in the 2021 edition, is retained and elevated in 2025. This reflects the industry's recognition that many security failures cannot be attributed to a specific implementation bug — they are consequences of architectural decisions that made secure implementation infeasible. A VAPT report that identifies insecure design findings alongside implementation bugs is more useful for security-mature organisations because it addresses the systemic causes of recurring issues.

Insecure design findings require different remediation guidance than implementation bugs. An implementation bug has a specific fix in a specific file; an insecure design finding may require refactoring across multiple modules, adopting a different authentication library, or changing the trust boundaries in the application architecture. VAPT reports should frame insecure design findings as design engagements requiring architectural review, not as issues that can be closed in a sprint.

Insecure design testing draws on threat modelling techniques applied against the observed application behaviour. The tester asks: given the observed authentication flow, what design changes could have prevented the identified vulnerabilities? Given the observed authorization model, what alternative model would have made the observed access control failures structurally impossible? Answering these questions produces the design-level findings that mature security programmes value most.

Security Misconfiguration and Cloud Complexity

Security Misconfiguration retains its high position in the 2025 revision. The distribution of misconfigurations has shifted from application-server settings toward cloud infrastructure configuration — cloud IAM policies, storage bucket permissions, container runtime settings, Kubernetes RBAC, and API gateway configurations. VAPT programmes need to assess this expanded surface area even when the primary application is well-configured.

Misconfiguration testing benefits enormously from automation because the set of possible misconfigurations is large but well-characterised. CIS Benchmarks, cloud provider best practices, and OWASP guidance define reference configurations that automated tooling can compare against actual environments systematically. VAPT reports should include misconfiguration findings mapped to specific benchmark controls with quantified drift from reference configuration.

The overlap between security misconfiguration and insecure design should be surfaced in reporting. A misconfiguration finding often points at a design issue in how configuration is managed — the same misconfiguration recurring across environments frequently indicates that the deployment pipeline lacks guardrails to prevent it. Framing misconfiguration findings in terms of the deployment pipeline that produced them makes remediation more sustainable than fixing each instance individually.

Aligning VAPT Reports to the 2025 List

VAPT reports have historically organised findings by severity or by application area. Aligning findings to the OWASP Top 10 categories in the report structure serves two purposes: it makes the report immediately legible to auditors and compliance stakeholders who use the OWASP list as a reference framework, and it makes coverage gaps visible. If a report has zero findings under "Broken Access Control" and hundreds under "Cryptographic Failures", the coverage of access control is probably inadequate rather than the application being genuinely strong there.

Compliance framework mappings should sit alongside OWASP Top 10 categorisation. PCI DSS Requirement 6.5 explicitly enumerates OWASP Top 10 categories that must be tested for; ASVS Level 2 and Level 3 requirements map to Top 10 categories systematically; ISO 27001 Annex A control A.8.29 relies implicitly on OWASP as the reference threat catalogue. Reports that map findings to OWASP categories and compliance framework requirements simultaneously satisfy both technical and audit stakeholders with a single document.

The transition to the 2025 revision should be treated as a scope review event, not just a categorisation update. Assessment methodologies that were adequate under the 2021 list may have gaps under 2025 — particularly in SSRF, supply chain, and access control depth. A defensive VAPT programme reviews its coverage after every major OWASP revision and updates test plans to close the gaps that the revision surfaces.