The OWASP Top 10 has been the gold standard for web application security awareness since its inception over two decades ago. The latest edition, OWASP Top 10:2025, confirmed in early 2026, is built on analysis of more than 175,000 real-world vulnerabilities. If you build, maintain, or commission web applications, this is your essential reading list for the year ahead.
TLDR
The OWASP Top 10:2025 reshuffles the risk landscape with two new categories (Software Supply Chain Failures and Mishandling of Exceptional Conditions), confirms Broken Access Control as the number one threat, and elevates Security Misconfiguration to second place. If your team is not addressing these risks, your applications are exposed.
Why the OWASP Top 10 Still Matters
Some developers treat the OWASP Top 10 as a compliance checkbox. That is a mistake. The list is compiled from real vulnerability data contributed by security firms, bug bounty programmes, and penetration testers worldwide. It reflects what attackers are actually exploiting, not theoretical risks.
With regulations like the EU’s NIS2 Directive and the Cyber Resilience Act (CRA) now explicitly referencing recognised security standards, the OWASP Top 10 has moved from “nice to have” to “better have it documented.” If your organisation handles customer data, processes payments, or exposes APIs, auditors and regulators will expect you to demonstrate awareness of these risks.
What Changed from 2021 to 2025
The 2025 edition is not a minor revision. Several categories have shifted position, one has been merged, and two entirely new categories have been introduced. Here is the full list with our take on what each means for development teams in 2026.
A01: Broken Access Control (Holds #1)
No surprise here. Broken access control remains the most prevalent risk in web applications. This covers everything from users escalating privileges to accessing data by tampering with URLs, API parameters, or direct object references. Server-Side Request Forgery (SSRF), previously its own category, has been merged into this one.
What to do: Implement server-side access control checks for every endpoint. Never rely on client-side validation alone. Test with automated tools and manual penetration testing to catch logic flaws that scanners miss.
A02: Security Misconfiguration (Up from #5)
This is a big mover. Security misconfiguration jumping to second place reflects a reality that DevOps teams know well: the faster you deploy, the easier it is to ship insecure defaults. Debug mode left on in production, overly permissive CORS headers, default credentials on cloud services, and missing security headers are all depressingly common.
What to do: Automate your security configuration checks. Use infrastructure-as-code tools with security linting. Conduct regular configuration audits, especially after major deployments or infrastructure changes.
A03: Software Supply Chain Failures (New)
This is the headline addition. The 2021 list had “Vulnerable and Outdated Components” at position 6. The 2025 edition expands this dramatically to encompass the entire software supply chain: package repositories, build systems, CI/CD pipelines, and third-party dependencies.
The reasoning is clear. High-profile supply chain attacks (think SolarWinds, the xz utils backdoor, and compromised npm packages) have demonstrated that a single poisoned dependency can cascade across thousands of applications. The Cyber Resilience Act is already pushing organisations toward maintaining a Software Bill of Materials (SBOM) for exactly this reason.
What to do: Maintain an SBOM for every application. Use dependency scanning tools (Snyk, Dependabot, or similar) in your CI/CD pipeline. Pin dependency versions and verify package integrity. Review your build pipeline security, not just your application code.
A04: Cryptographic Failures (Down from #2)
Dropping two places does not mean cryptography is sorted. This category covers insufficient encryption of data in transit or at rest: no HTTPS enforcement, weak hashing algorithms, missing salting on password storage, and improper key management. The slight dip in ranking reflects better default behaviour in modern frameworks, but legacy systems and custom implementations remain vulnerable.
What to do: Enforce HTTPS everywhere. Use bcrypt or Argon2 for password hashing. Audit your key management practices. If you are still using MD5 or SHA-1 for anything security-sensitive, stop.
A05: Injection (Down from #3)
SQL injection, XSS, and command injection remain dangerous, but modern frameworks with parameterised queries and output encoding have reduced their prevalence. The risk has not disappeared; it has shifted to legacy applications, custom code, and environments where frameworks are not used correctly.
What to do: Use parameterised queries and prepared statements. Enable Content Security Policy headers. Validate and sanitise all user input on the server side. Pay extra attention to legacy codebases during security reviews.
A06: Insecure Design (Holds #6)
This category addresses a fundamental truth: you cannot bolt security onto a flawed design. If the business logic itself is insecure, no amount of code-level fixes will help. Think rate limiting on authentication endpoints, or ensuring that a discount code cannot be applied multiple times through API manipulation.
What to do: Incorporate threat modelling early in the design phase. Use abuse cases alongside use cases. Conduct design reviews with security in mind before writing a single line of code.
A07: Authentication Failures (Renamed, Holds #7)
Weak password recovery flows, missing multi-factor authentication (MFA), and session management issues all fall here. In 2026, relying on passwords alone for critical applications is simply not acceptable. FIDO2 and passkeys are becoming the expected standard.
What to do: Implement MFA for all user-facing applications. Support passkeys where possible. Use proven authentication libraries rather than rolling your own. Rate-limit login attempts and monitor for credential stuffing.
A08: Software or Data Integrity Failures (Holds #8)
This covers situations where code or data is trusted without verification. Unsigned software updates, insecure deserialisation, and unverified CI/CD pipeline outputs all qualify. With supply chain attacks on the rise, integrity verification is no longer optional.
What to do: Sign your releases. Verify the integrity of third-party packages. Implement Subresource Integrity (SRI) for CDN-hosted assets. Review your deserialisation practices.
A09: Security Logging and Alerting Failures (Expanded)
The 2025 edition emphasises that logging alone is worthless without alerting. If you record every event but nobody monitors the logs, you will not detect a breach until the damage is done. This category now explicitly calls out the need for active monitoring and incident response capabilities.
What to do: Implement centralised logging with real-time alerting. Define what constitutes a security event and ensure it triggers a response. Test your alerting pipeline regularly. Keep logs tamper-resistant and retain them for an appropriate period.
A10: Mishandling of Exceptional Conditions (New)
The second new category addresses how applications handle unexpected situations: unhandled exceptions that leak stack traces, error messages exposing internal architecture, and edge cases that bypass security controls. Poor exception handling can reveal information that makes other attacks easier.
What to do: Implement global error handlers that return generic error messages to users. Log detailed errors server-side only. Test edge cases and boundary conditions. Ensure that exceptions do not bypass authentication or authorisation checks.
What This Means for Your Business
The OWASP Top 10:2025 is not just a developer’s reading list. It is a business risk document. Every category represents a potential data breach, regulatory fine, or reputational hit. The introduction of supply chain security as a top-three risk reflects the reality that your application is only as secure as its weakest dependency.
For organisations building or maintaining web applications, the practical steps are clear:
- Audit regularly. Annual penetration tests are a minimum. Continuous security scanning is better.
- Shift left. Incorporate security into design and development, not just testing.
- Know your dependencies. Maintain an SBOM and monitor for vulnerabilities in your supply chain.
- Train your team. Developers who understand the OWASP Top 10 write more secure code by default.
At REPTILEHAUS, we build security into every project from day one. Whether it is a SaaS platform, a Web3 application, or an API integration, our development process incorporates threat modelling, dependency auditing, and security testing as standard practice. If your applications need a security review or you are planning a new build and want to get it right from the start, get in touch.
📷 Photo by Zulfugar Karimov on Unsplash
