OWASP Top 10 2025: What’s Changed?
For years, the OWASP Top 10 has operated as the gold standard for highlighting the most critical web application security risks.
The 2025 edition arrives at a time when application environments are becoming increasingly complex. Cloud-native architectures, software supply chain risks, APIs and AI-assisted development are all changing the way applications are built and secured. As a result, the latest update provides insight into how application security priorities are evolving and where organizations should focus their efforts over the coming years.
What’s new in the OWASP Top 10 for 2025?
OWASP made it clear that the focus of the 2025 edition is still, as far as possible, focused on the root cause of application security risk rather than the symptoms. Many familiar categories remain, but OWASP has introduced two notable changes that acknowledge the growing complexity of today’s software ecosystems.

How the OWASP Top 10 for 2025 differs from the 2021 edition (source: OWASP)
Software Supply Chain Failures enters the Top 10
Arguably the biggest addition is A03:2025 – Software Supply Chain Failures, which expands on the narrower “Vulnerable and Outdated Components” category from 2021. Rather than focusing solely on vulnerable libraries, the new category considers the entire software supply chain, including dependencies, build systems, package repositories and software distribution mechanisms.
This change reflects that applications today rarely consist entirely of internally developed code. Open-source components, third-party packages and automated CI/CD pipelines are now fundamental parts of the development process. As a result, attackers increasingly target the software supply chain itself, reflected in this category experiencing the highest average exploit and impact scores from CVEs.
In one recent incident, Microsoft’s durabletask Python SDK was compromised on PyPI. This package is downloaded over 400,000 times per month, and is the official SDK for Azure Durable Functions. On May 19th 2026, three malicious versions were published to PyPI, which executes a payload that steals credentials and then spreads through cloud infrastructures.
Mishandling of Exceptional Conditions makes its debut
The second new category is A10:2025 – Mishandling of Exceptional Conditions. This focuses on how applications behave when things go wrong, including improper error handling, resource exhaustion, unexpected inputs and other failure scenarios that can create security weaknesses.
While secure coding guidance has traditionally focused on preventing vulnerabilities during normal operation, this category highlights the importance of resilience under abnormal conditions. An application may function securely most of the time, but still expose sensitive information, crash unexpectedly or become susceptible to denial-of-service attacks when faced with edge cases that developers did not anticipate.
A broader shift towards systemic risk
Perhaps the most interesting development isn’t the arrival of new categories, but what they represent. The 2025 update continues OWASP’s gradual move away from individual coding mistakes and towards broader weaknesses in software design, development processes and operational practices. In other words, application security is increasingly becoming a question of how software is built and maintained, not just whether developers are writing secure code.
The OWASP Top 10 for 2025
| OWASP Top 10 2025 Risk | What It Means | Key Mitigations |
| A01: Broken Access Control | Users can access data, systems, or functions they should not be allowed to use. | Enforce least privilege, apply server-side authorization checks, deny access by default (except for public resources), and review permissions regularly. |
| A02: Security Misconfiguration | Applications, cloud services, servers, or systems are deployed with insecure settings. | Harden configurations, remove unused features and services, and automate secure configuration management. |
| A03: Software Supply Chain Failures | Weaknesses are introduced through third-party software, dependencies, build systems, or delivery pipelines. | Maintain a software inventory, use dependency scanning, generate Software Bill of Materials (SBOMs), verify package integrity, and secure build and deployment pipelines. |
| A04: Cryptographic Failures | Sensitive data is not properly protected because encryption, hashing, key management, or transport security is weak or missing. | Use modern encryption standards while avoiding deprecated algorithms and protocols, protect data at rest and in transit, and manage keys securely. |
| A05: Injection | Untrusted input is processed as a command or query, allowing attackers to manipulate how the application behaves. | Use parameterized queries, validate input, apply output encoding, avoid unsafe interpreters, and include injection testing in development and assurance processes. |
| A06: Insecure Design | This is a broad category whereby there are missing or ineffective controls in an application’s development or deployment. | Use threat modeling, define security requirements early, apply secure-by-design principles, and review high-risk workflows before development. |
| A07: Authentication Failures | Login, identity, or session controls are weak enough to let attackers impersonate legitimate users. | Enforce multi-factor authentication (MFA), use strong password and session controls, protect against brute-force attacks, and monitor for suspicious login behavior. |
| A08: Software or Data Integrity Failures | Applications trust software updates, code, data, or pipelines without properly verifying their integrity. | Use code signing, integrity checks, protected deployment workflows, strong access controls, and change approval processes. |
| A09: Security Logging and Alerting Failures | Security-relevant events are not logged, monitored, or acted on effectively. | Log security-relevant events, protect logs from tampering, configure actionable alerts, and regularly test monitoring and incident response processes. |
| A10: Mishandling of Exceptional Conditions | Applications fail to prevent, detect or respond to unusual situations. | Implement secure error handling, test edge cases, enforce resource limits, avoid exposing stack traces, and ensure applications fail securely. |
What the 2025 update says about the future of AppSec
The 2025 edition makes one thing clear: AppSec is no longer just about finding bugs in code. Managing risk across the entire software lifecycle is now the key focus for security teams.
Secure coding is as crucial as ever, but many critical risks now sit earlier in the process. Insecure design, broken access controls and cryptographic failures are difficult to fix with a last-minute scan before release. They need to be considered when teams are defining requirements, designing user journeys, choosing architectures and deciding how data should move through an application.
The categories Software Supply Chain Failures and Software and Data Integrity Failures point directly to the way applications are built, assembled and deployed. Dependencies, CI/CD pipelines, package repositories, build systems and release processes are now part of the attack surface. For organizations, that means security controls need to be embedded into development workflows rather than treated as separate checks owned only by the security team.
The 2025 list also highlights the growing importance of resilience. Security Logging and Alerting Failures and Mishandling of Exceptional Conditions both show that prevention alone is not enough. If an application fails, it needs to do so in a way that generates useful signals. This gives teams enough visibility to detect and respond to attacks quickly.
For AppSec teams, the message is not to abandon vulnerability management, but to broaden the scope. Testing for injection flaws and outdated components remains important, but it should sit alongside threat modeling, secure design reviews, identity and access control testing, pipeline hardening and better operational monitoring.
In short, the OWASP Top 10:2025 reflects an application security discipline that is becoming more architectural and more closely tied to how software is delivered. The organizations best placed to respond will be those that make security a normal part of building software, not a final hurdle before it goes live.
How Outpost24 helps organizations secure their web applications
Against the challenges facing secure web application development and deployment, point-in-time security assessments can struggle to keep pace.
With CyberFlex, Outpost24 provides a flexible Penetration Testing as a Service (PTaaS) solution that helps organizations identify and address web application vulnerabilities throughout the development lifecycle. Rather than relying solely on annual or compliance-driven assessments, security teams gain access to dynamic testing, expert-led validation, and actionable findings through a single platform.
CyberFlex delivers a flexible program aligned to your priorities, so every penetration test delivers the most value. Continuous discovery helps you identify known, unknown and unmanaged applications across your external attack surface, while certified testers validate vulnerabilities and provide clear remediation guidance.
Ready to take a more proactive approach to web application security? Contact us today or book a demo to see our solutions in action.