The OWASP Top 10 2025 represents the most significant revision to the world's most widely referenced web application security standard in years. With two entirely new categories, several position shifts, and updated guidance reflecting the modern threat landscape, this release demands attention from every development and security team. Whether you are a startup shipping your first SaaS product or a mid-market company managing dozens of microservices, understanding the OWASP Top 10 2025 is essential for building secure software and passing compliance audits. In this guide, we break down every category, explain what changed, and provide concrete remediation steps you can start implementing today.
Why the OWASP Top 10 Still Matters in 2025
The OWASP Top 10 has been the de facto standard for web application security awareness since its first publication in 2003. Regulatory frameworks like PCI DSS, SOC 2, and HIPAA reference it directly or indirectly. Compliance auditors expect you to demonstrate coverage against these categories. More importantly, the list is compiled from real-world vulnerability data contributed by hundreds of organizations worldwide, making it a reliable barometer of the threats that actually affect production applications.
The 2025 update draws from over 500,000 data points spanning 2021 through 2024. The methodology incorporated both incidence data (how often a vulnerability class appears) and exploitability weighting (how easily and severely it can be exploited). The result is a list that better reflects the risks teams face right now, not three years ago. If your last web application penetration test referenced the 2021 list, it is time to recalibrate.
A01:2025 - Broken Access Control (Still Number One)
Broken Access Control has held the top position since 2021, and the 2025 data confirms it remains the most prevalent and impactful vulnerability class. This category covers any situation where users can act outside their intended permissions: accessing another user's data, escalating privileges, modifying records they should not touch, or bypassing authorization checks entirely.
Common patterns we encounter during penetration testing engagements include insecure direct object references (IDOR), missing function-level access controls on admin endpoints, and JWT token manipulation. The prevalence of single-page applications and API-first architectures has only amplified these issues, since authorization logic is frequently split between frontend and backend with gaps in between.
Remediation steps: Implement server-side authorization checks on every endpoint. Use a centralized access control mechanism rather than scattering checks across individual routes. Deny by default. Write integration tests that specifically verify authorization boundaries. During code reviews, flag any endpoint that retrieves data based on a user-supplied ID without verifying ownership.
A02:2025 - Security Misconfiguration (Moved Up from #5)
Security Misconfiguration has jumped from the fifth position to second, reflecting the explosion of cloud infrastructure, container orchestration, and infrastructure-as-code deployments where a single misconfigured setting can expose an entire environment. This category now also absorbs what was previously a separate entry for XML External Entities (XXE).
The shift to cloud-native architectures means that misconfiguration now extends far beyond web server settings. We routinely find overly permissive S3 bucket policies, Kubernetes RBAC misconfigurations, default credentials on administrative interfaces, unnecessary HTTP methods enabled, verbose error messages leaking stack traces, and missing security headers. The attack surface for misconfiguration has grown dramatically.
Remediation steps: Establish hardened baseline configurations for every technology in your stack. Automate configuration validation using tools like Open Policy Agent, AWS Config Rules, or Terraform Sentinel policies. Remove default accounts and passwords. Disable directory listing, unnecessary features, and debug endpoints in production. Implement security headers (Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security) across all responses. Conduct regular configuration reviews as part of your security program.
A03:2025 - Software Supply Chain Failures (New Entry)
This is one of two entirely new categories in the 2025 update, and it reflects a seismic shift in how modern applications are built and attacked. Software Supply Chain Failures covers vulnerabilities introduced through third-party dependencies, compromised build pipelines, malicious packages, and inadequate verification of software components. The SolarWinds, Log4Shell, and XZ Utils incidents made this category impossible to ignore any longer.
Modern applications routinely pull in hundreds or thousands of transitive dependencies. A single compromised package can affect millions of downstream applications. This category goes beyond just "use an SCA tool" and encompasses build system integrity, artifact signing, provenance verification, and vendor risk management.
We wrote an in-depth analysis of this threat in our software supply chain security guide that covers practical mitigation strategies.
Remediation steps: Maintain a complete software bill of materials (SBOM) for every application. Pin dependency versions and verify checksums. Use lock files and audit them in CI/CD. Implement dependency scanning with tools like Snyk, Dependabot, or Trivy. Evaluate the security posture of critical dependencies. Sign build artifacts and verify signatures during deployment. Restrict access to build pipelines and treat them as production infrastructure.
A04:2025 - Injection (Moved Down from #3)
Injection has gradually declined in ranking over successive OWASP updates, not because it has become less dangerous but because frameworks and ORMs have made basic SQL injection harder to introduce accidentally. However, injection remains a critical risk. The category encompasses SQL injection, NoSQL injection, OS command injection, LDAP injection, and expression language injection.
What has changed is the attack surface. While traditional SQL injection in form inputs has decreased, injection vulnerabilities in API parameters, GraphQL queries, server-side template engines, and ORM-layer raw queries continue to appear regularly. The consequences remain severe: data exfiltration, authentication bypass, and in some cases full system compromise.
Remediation steps: Use parameterized queries or prepared statements exclusively. Never concatenate user input into queries or commands. Validate and sanitize input on the server side. Apply the principle of least privilege to database accounts. Use ORMs carefully and audit any raw query usage. Include injection testing in your penetration testing scope.
A05:2025 - Cryptographic Failures (Stable)
Previously known as "Sensitive Data Exposure," this category maintains its focus on failures related to cryptography and data protection. It covers weak or broken encryption algorithms, improper key management, transmission of data in cleartext, use of deprecated hash functions, and insufficient protection of sensitive data at rest.
Common findings include applications still using MD5 or SHA-1 for password hashing instead of bcrypt or Argon2, TLS 1.0/1.1 still enabled on production servers, hard-coded encryption keys in source code, and sensitive data stored in application logs. With increasingly strict data protection regulations, cryptographic failures carry both technical and legal risk.
Remediation steps: Use strong, modern algorithms (AES-256 for encryption, bcrypt/Argon2 for password hashing, TLS 1.3 for transport). Manage keys through a dedicated secrets management system such as AWS KMS, HashiCorp Vault, or Azure Key Vault. Classify your data to know what requires encryption. Disable legacy TLS versions. Audit your codebase for hard-coded secrets and remove them.
A06:2025 - Vulnerable and Outdated Components (Stable)
This category addresses the risk of using libraries, frameworks, and other software components with known vulnerabilities. While it overlaps somewhat with the new Supply Chain Failures category, it specifically focuses on the patching and lifecycle management of components you already depend on, rather than the introduction of malicious components.
The challenge is scale. A typical Node.js application can have over a thousand transitive dependencies. Keeping track of which versions are installed, which have known CVEs, and which are end-of-life requires automation. Organizations that rely on manual tracking inevitably fall behind.
Remediation steps: Integrate software composition analysis (SCA) into your CI/CD pipeline. Set policies to block builds with high-severity vulnerabilities. Monitor for new CVEs affecting your dependency tree continuously. Remove unused dependencies. Plan for framework upgrades before they reach end-of-life. Document exceptions with explicit risk acceptance.
A07:2025 - Identification and Authentication Failures (Moved Down)
Authentication-related vulnerabilities have moved down the list as adoption of multi-factor authentication, identity providers, and passkeys has improved. However, this category remains critically important. It covers weak passwords, credential stuffing, session fixation, improper session invalidation, and missing MFA on sensitive operations.
We still find applications that allow unlimited login attempts without rate limiting, store session tokens in URLs, fail to invalidate sessions on password change, or implement "remember me" functionality insecurely. API authentication issues, particularly around bearer token management and OAuth implementation flaws, are increasingly common.
Remediation steps: Implement MFA for all user accounts, especially privileged ones. Use established authentication libraries and identity providers rather than rolling your own. Enforce strong password policies and check against breached password databases. Implement account lockout or progressive delays. Rotate session IDs after authentication. Set appropriate session timeouts.
A08:2025 - Software and Data Integrity Failures (Stable)
This category focuses on code and infrastructure that does not protect against integrity violations. It includes insecure deserialization, CI/CD pipeline integrity issues, and auto-update mechanisms that download updates without verifying signatures. Applications that rely on untrusted sources for plugins, libraries, or CDN resources without integrity checks fall into this category.
Remediation steps: Use digital signatures or checksums to verify software and data integrity. Implement Subresource Integrity (SRI) for external scripts loaded from CDNs. Secure your CI/CD pipeline with signed commits, branch protection rules, and environment separation. Avoid deserializing data from untrusted sources, or use serialization formats that do not allow object instantiation.
A09:2025 - Security Logging and Monitoring Failures (Stable)
Without adequate logging and monitoring, breaches go undetected for months. This category addresses insufficient logging of security-relevant events, lack of alerting on suspicious activity, and inability to detect or respond to active attacks. The median time to detect a breach is still measured in weeks, and inadequate monitoring is a primary contributor.
Remediation steps: Log all authentication events, access control failures, input validation failures, and administrative actions. Centralize logs in a SIEM or log management platform. Set up alerts for anomalous patterns such as brute force attempts, privilege escalation, or unusual data access volumes. Test your detection capabilities periodically. Ensure logs are tamper-proof and retained for an appropriate period.
A10:2025 - Mishandling of Exceptional Conditions (New Entry)
The second new entry in the OWASP Top 10 2025, this category addresses a class of vulnerabilities that has been consistently overlooked: how applications behave when things go wrong. Mishandling of Exceptional Conditions covers improper error handling, uncaught exceptions that leak sensitive information, race conditions, resource exhaustion, and failure states that bypass security controls.
Real-world examples include applications that fall back to an "allow all" state when an authorization service is unreachable, payment systems that process transactions when validation throws an exception, and APIs that return full database error messages including table names and query structures. These issues are often missed by automated scanners because they require understanding the application's intended behavior.
Remediation steps: Implement global exception handlers that return generic error messages to users while logging detailed information internally. Design fail-closed systems where errors result in denied access rather than open access. Handle all expected exception types explicitly. Implement circuit breakers for external service calls. Test error handling paths specifically, including timeout scenarios, invalid states, and resource exhaustion. Include error handling review in your code review checklist.
How Penetration Testing Maps to the OWASP Top 10 2025
A thorough penetration test should cover every category in the OWASP Top 10, but the depth and approach varies by category. Access control testing requires manual exploration of authorization boundaries with authenticated sessions. Injection testing combines automated scanning with manual payload crafting. Supply chain assessment involves reviewing dependency manifests, build configurations, and deployment pipelines.
At Lorikeet Security, our web application penetration testing methodology is explicitly mapped to the OWASP Top 10 categories. Each finding in our reports references the applicable OWASP category, making it straightforward for your team to prioritize remediation and for auditors to verify coverage. We serve startups and mid-market companies across all service areas with engagements starting at $2,500.
The two new categories in the 2025 update deserve special attention in your next assessment. Supply chain testing requires access to your dependency manifests and build pipeline configuration. Exceptional condition testing requires creative negative testing that goes beyond standard vulnerability scanning. Both benefit significantly from experienced manual testers who understand how applications fail in production.
Preparing Your Team for the 2025 Changes
Updating your security program to reflect the OWASP Top 10 2025 involves more than reading this article. Here is a practical roadmap:
First, conduct a gap analysis. Map your current security controls against the updated list. Pay special attention to the two new categories: Software Supply Chain Failures and Mishandling of Exceptional Conditions. These likely have the least coverage in your existing program.
Second, update your secure development training. Ensure your developers understand the new categories and can recognize these vulnerability patterns in code review. The supply chain category in particular requires awareness at the architectural level, not just the coding level.
Third, update your testing scope. Whether you conduct penetration testing internally or work with a firm like Lorikeet Security, make sure your test plans explicitly cover all ten categories. Our team can help you design a testing program that aligns with the 2025 update.
Fourth, review your CI/CD pipeline security. The new supply chain category makes build pipeline integrity a first-class security concern. Treat your build infrastructure with the same rigor you apply to production systems.
Finally, schedule a comprehensive penetration test against the updated standard. The sooner you identify gaps, the sooner you can close them before attackers or auditors find them first.
Align Your Security Program with OWASP Top 10 2025
Our penetration testing methodology maps directly to every OWASP Top 10 category. Get a comprehensive assessment that identifies gaps and provides actionable remediation guidance for your development team.
