OWASP Top 10 for 2025

The new list of top 10 security risks from OWASP for web applications

The OWASP¹ Top 10 list for 2025 has been released, four years after its previous iteration. The list is a general assessment of significant risks in web application security. Its structure and changes from the 2021 list offer insight into the state of the industry, highlighting areas where we are improving and, more often, where we continue to fail. These are my brief thoughts on the list in general.

1. Broken Access Control (A01:2025) 👑

Broken Access Control occurs when an application fails to enforce restrictions on authenticated users, allowing them to act outside their intended permissions. This includes bypassing authorization checks, accessing unauthorized resources, or performing privileged actions without proper validation. Examples include authorization bypass using Insecure Direct Object Reference.

This category remains at the top, which speaks volumes about the difficulty of implementing effective authorization models in complex systems. It now incorporates the 2021’s No. 10 Server Side Request Forgery (SSRF).

2. Security Misconfiguration (A02:2025) ⚙️

Security Misconfiguration refers to improper implementation of security controls across any layer of the application stack: network, web servers, databases, or cloud configurations. Examples include default credentials, public cloud buckets, missing security headers, misconfigured CORS policies, or unnecessary features enabled (e.g., verbose error messages, admin interfaces).

This category is a notable jump from #6 to #2. This is less a failure of technology and more a failure of process. Misconfigurations, such as leaked credentials, are a direct result of complexity. The axiom “complexity is the worst enemy of security” holds true here.

3. Software Supply Chain Failures (A03:2025) 📦

Software Supply Chain Failures refer to security risks introduced through third-party components, libraries, tools, or services integrated into an application. These failures occur when external dependencies are compromised, outdated, or poorly managed, leading to vulnerabilities that propagate across systems.

This category expands on 2021’s “Vulnerable and Outdated Components.” The SolarWinds and Log4j incidents demonstrated the systemic risk of modern software development and spiral dependencies. We are building systems with components we do not control or fully understand - a robust third party risk management is needed here.

4. Cryptographic Failures (A04:2025) 🔑

Cryptographic failures refer to the improper implementation, configuration, or usage of cryptographic mechanisms intended to protect data in transit or at rest. This includes weak or outdated algorithms, insecure key generation or storage, missing encryption altogether (sadly still prevalent), or misuse of protocols (TLS 1.2 vs TLS 1.3).

This category has dropped two slots from #2 suggests some progress, but this area remains critical. The core problem often lies not in the algorithms themselves but in their implementation and key management. Dance like no one is watching. Encrypt like everyone is.

5. Injection (A05:2025) 💉

Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query. This allows attackers to alter the intended logic of the program, often leading to unauthorized access, data leakage, or system compromise.

Injection attacks have been a known risk for decades; this category has dropped 2 slots from 2021’s No. 3 (and 2017’s No. 1). They includes a range of issues from Cross-site Scripting (high frequency/low impact) to SQL Injection (low frequency/high impact) vulnerabilities. “Prompt Injection” for LLMs is no. 1 in the OWASP Top 10 for LLM 2025 list - so injection attacks as a category are not going anywhere unfortunately.

6. Insecure Design (A06:2025) 📐

Insecure Design refers to flaws in the architecture and design of an application that create inherent security weaknesses, regardless of how well the implementation is executed. Unlike implementation bugs, insecure design is about what is built, not how it’s built. Examples include client-side enforcing security logic, lack of authentication or authorization mechanisms consistently, absence of secure defaults, direct object reference without access control, missing logging at key interfaces, etc.

This category, introduced in 2021, reflects the industry’s growing recognition that security needs to be considered at the design phase, not as an afterthought. This requires a shift in mindset across the development lifecycle.

7. Authentication Failures (A07:2025) ✅

Authentication failures occur when an application incorrectly implements identity verification mechanisms, allowing attackers to compromise credentials, bypass login systems, or impersonate users.

This categories is in a steady position on the list at #7. Despite improvements through standardized frameworks (like OAuth2, OpenID Connect, and SAML), misconfigurations and poor implementation still expose systems to brute-force attacks, credential stuffing, and session hijacking. The risk is amplified in APIs and mobile apps where tokens and credentials are often mishandled.

8. Software or Data Integrity Failures (A08:2025) ⚖️

Software or Data Integrity Failures occur when a system fails to adequately protect the consistency and trustworthiness (“integrity”) of its code, configuration, or data, particularly when processing input from untrusted sources or updating code components. This includes issues like allowing unverified serialization-deserialization of sensitive objects, failing to use cryptographic checks (like hashes or digital signatures) on firmware updates, or trusting input without validation, encoding, or proper type and schema verification.

This category is remaining at #8. It emphasizes the need to verify the integrity of data and code. In this AI era (yes, I said it - AI era) , where data poisoning can have significant consequences, ensuring data has not been tampered with is essential for trustworthy systems.

9. Logging & Alerting Failures (A09:2025) 🚨

This vulnerability arises when security-relevant events are not properly recorded, monitored, or acted upon. It includes missing, insufficient, or improperly configured logging mechanisms, as well as the absence of timely alerting systems that can detect and escalate suspicious activity.

This category has a slight name change (previously “Security Logging and Monitoring Failures”). Per OWASP, the name change emphasizes the necessity of detection as well as response capabilities. It is not enough to simply log events; we need effective alerting mechanisms to identify and act on security incidents in a timely manner. Great logging with no intelligent alerting is of minimal value.

10. Mishandling of Exceptional Conditions (A10:2025) 🤯

Mishandling of Exceptional Conditions occurs when systems fail to properly handle unexpected or abnormal conditions. Examples include failing to roll back failed operations entirely, exposing detailed stack traces in error messages, or allowing race conditions where the security state is incorrectly calculated or manipulated.

This category is a new entry on the list. This points to the need for systems to fail securely (a secure design principle) and handle unexpected events gracefully. Flaws here can lead to race conditions or replay attacks - this precise concept led to a recent cloud outage. It’s a reminder that security must consider not just the “happy path” of system operation, but also what happens when things go wrong.

So what?

The OWASP Top 10 is a useful tool for prioritizing security efforts. But the list itself is a symptom of a larger, systemic problem: our inability to build secure software in the first place. The 2025 update shows that while some categories shift, the core issues remain stubbornly familiar: access control, misconfiguration, supply chain risk, and insecure design. These are not just technical problems - they’re organizational, procedural, and cultural. We must move beyond simply addressing this list and start addressing the fundamental engineering and process issues that generate these vulnerabilities.

1. OWASP stands for the Open Worldwide Application Security Project, a non-profit foundation dedicated to improving the security of software.