The OWASP Top 10 Just Got a Fresh Update: Supply Chain Attacks, Exceptional Condition Handling, and More

The Open Web Application Security Project (OWASP) has released its latest iteration of the OWASP Top 10, a widely recognized standard for web application security risks. This significant update introduces new vulnerabilities and re-prioritizes existing ones, reflecting the evolving threat landscape. Security expert Tanya Janca joined the "Talk Python To Me" podcast to provide an in-depth analysis of these changes, emphasizing practical implications and real-world applications.

Background: The Significance of the OWASP Top 10

The OWASP Top 10 serves as a crucial awareness document for developers, security professionals, and organizations worldwide. First published in 2003, it is updated periodically to reflect the most critical security risks facing web applications. The list is compiled based on extensive data analysis from various sources, including penetration testing reports, vulnerability disclosures, and industry surveys. Its primary goal is to educate and guide the software development community in building more secure applications.

The OWASP Foundation, a non-profit organization, is dedicated to improving software security through community-driven efforts. With over 300 chapters globally and more than 100 active open-source projects, OWASP fosters a collaborative environment for advancing application security. Janca, a long-time contributor and distinguished member of OWASP, highlighted the organization’s extensive reach and commitment to providing free resources like books, tools, and documentation.

Key Changes in the 2025 OWASP Top 10

The 2025 update brings several notable shifts, with a particular focus on emerging threats and systemic issues. Janca detailed these changes, emphasizing how they impact modern software development practices.

• Software Supply Chain Failures (A03:2025): This category, expanded from the previous "Vulnerable and Outdated Components," now encompasses a broader spectrum of risks within the software supply chain. Janca explained that "every single thing that you use to create and maintain your software is part of your supply chain." This includes development tools, libraries, packages, CI/CD pipelines, and even the development environment. The update acknowledges that malicious actors are increasingly targeting developers themselves, compromising their machines or credentials to infiltrate the supply chain. Recent high-profile breaches, such as the SolarWinds attack, underscore the devastating impact of such compromises, where a deeply embedded vulnerability allowed attackers to distribute malicious code disguised as legitimate updates to a vast number of customers. The OWASP update stresses the need to protect the entire supply chain, from the initial download of dependencies to their integration into the final product. Practical advice for Python developers includes pinning dependencies using tools like pip-compile or uv lock to ensure reproducible builds and prevent unexpected updates. Furthermore, developers are urged to actively check for known vulnerabilities in packages before installation, a step often overlooked. The concept of "reachability" is also crucial here, meaning that a vulnerability is only a risk if there’s a path for it to be exploited by the application’s code. While many Software Composition Analysis (SCA) tools exist, Janca noted that the definition of "supply chain tool" has become broad, and a nuanced approach is needed to differentiate tools that address specific attack surfaces within the supply chain.

• Insecure Design (A06:2025): This is a new addition to the Top 10, distinguishing itself as the only category focused on the design phase rather than implementation. Janca emphasized that "it does not matter how perfectly you follow the plan if the plan is bad." This category addresses risks stemming from flawed architectural decisions, lack of security considerations during the design process, and inadequate threat modeling. Examples include failing to implement security controls like rate limiting, missing API gateways for publicly accessible APIs, or relying solely on client-side validation without server-side enforcement. The OWASP committee recognized that many vulnerabilities arise not from coding errors but from fundamental design flaws that are difficult to patch later. The absence of security reviews and a lack of explicit security requirements in the design phase contribute significantly to this category.

• Mishandling of Exceptional Conditions (A10:2025): Another new entry, this category addresses the failure to properly handle errors and exceptions within an application. Janca explained that this can manifest in various ways, such as empty catch blocks that silently ignore errors, or revealing sensitive system information like stack traces and internal error messages to users. Such practices can expose vulnerabilities, aid attackers in understanding the application’s internal workings, or lead to corrupted data due to unhandled exceptions in critical operations like database transactions. The OWASP committee emphasized the importance of application resilience, which requires robust error handling to ensure graceful degradation and proper recovery mechanisms. The lack of comprehensive security logging, particularly for failed security control attempts, is also a significant contributor to this risk, hindering incident response and investigation.

• Broken Access Control (A01:2025): Moving up to the top spot, broken access control remains a pervasive and critical vulnerability. Janca noted that security experts consistently find this issue in penetration tests. This category covers flaws where users can gain unauthorized access to sensitive data or perform actions outside their permitted roles. Examples include inadequate checks on every page, record, or access point, allowing users to bypass authorization controls or access data intended for administrators. The complexity arises from the need to consistently enforce authorization for every request, ensuring that a user’s session remains valid and that they only have access to the resources they are supposed to. The OWASP update highlights the difficulty in implementing robust access control correctly and the temptation for developers to offload this responsibility to the front end or retrieve entire data sets and filter them client-side, which is a common pitfall.

• Cryptographic Failures (A04:2025): Previously known as "Sensitive Data Exposure," this category now focuses specifically on cryptographic weaknesses. Janca pointed out that this includes not encrypting data that should be protected, using outdated or weak encryption algorithms, and failing to encrypt data consistently. The practice of storing passwords with reversible encryption, rather than secure hashing with salting and peppering, falls under this category. The importance of using modern, memory-hard hashing algorithms like Argon2 is emphasized to protect against brute-force attacks. The OWASP update also addresses the silent failures that can occur with cryptographic implementations, where data might be intermittently unencrypted, posing a significant risk.

• Authentication Failures (A07:2025): This category consolidates various flaws related to authentication mechanisms. Janca highlighted the common mistakes of building custom authentication instead of leveraging robust, well-tested solutions, and the failure to implement protections against credential stuffing and brute-force attacks. Weak password policies, reuse of passwords, and the absence of multi-factor authentication (MFA) are significant contributors. The update acknowledges that MFA can be implemented in user-friendly ways, such as device fingerprinting and trusting secure devices, to reduce friction without compromising security. The rise of passkeys also signifies a move towards more secure and convenient authentication methods.

• Injection (A05:2025): Remaining a critical threat, injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. Janca referenced the classic "Little Bobby Tables" example of SQL injection and noted that similar vulnerabilities exist in other contexts, such as NoSQL injection when handling JSON data. The core principle is to prevent the mixing of data with executable code or commands. This includes using parameterized queries, prepared statements, and proper input validation to ensure that data is treated strictly as data and not interpreted as code. Escaping or sanitizing special characters is also crucial to prevent malicious input from altering the intended query or command.

• Insecure Design, Security Logging and Alerting, and Server-Side Request Forgery (SSRF) (New additions): The 2025 OWASP Top 10 sees the introduction of several new categories that reflect current security challenges.

  • Insecure Design (A06:2025) addresses flaws in the fundamental architecture and design of applications.
  • Security Logging and Alerting (A09:2025) focuses on the critical need for comprehensive logging of security-relevant events, including the success or failure of security controls. Insufficient logging hinders incident investigation and response, making it difficult to understand the scope and impact of an attack.
  • Server-Side Request Forgery (SSRF) (A08:2025) is another significant addition, highlighting the vulnerability where an attacker can induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing. This can lead to accessing internal systems, scanning internal networks, or interacting with other services that are not directly exposed to the internet.

Leveraging AI for Secure Coding

The conversation also delved into the role of Artificial Intelligence (AI) in software development and security. Janca shared her experiences using AI tools, like Claude Code, to generate and review code. She noted that while AI models are improving, they are often trained on vast datasets of existing code, much of which may contain security flaws or lack security best practices. This means that AI-generated code can sometimes inherit these weaknesses.

Janca has developed a "Secure Code Prompt Library" available for free on her website, SheHacksPurple.ca. This library provides prompts designed to guide AI models in generating more secure code and to assist developers in reviewing code for vulnerabilities. The library offers tiered prompts, from basic security principles to specific requirements for APIs and serverless applications, and even detailed guidance on secure practices like password hashing. She emphasized that by prompting AI models correctly, developers can significantly improve the security posture of the code they generate. A key technique involves asking the AI to list its security assumptions, which can reveal potential oversights or insecure default configurations.

Broader Implications and Future Outlook

The updated OWASP Top 10 underscores the growing complexity of web application security. The increased emphasis on supply chain security, insecure design, and exceptional condition handling reflects a shift towards a more holistic and proactive approach to security. Organizations must move beyond simply fixing code vulnerabilities and instead focus on building security into the entire software development lifecycle, from initial design to ongoing maintenance.

Janca’s call for a secure coding law in Canada, currently progressing through a parliamentary petition, highlights the growing recognition of the need for regulatory measures to ensure software security. Such initiatives, if successful, could set a precedent for other countries and drive broader adoption of secure coding practices across the industry.

The OWASP Top 10 remains an indispensable resource for anyone involved in web application security. By understanding these risks and adopting the recommended practices, developers and organizations can build more resilient and secure software in an increasingly threat-filled digital landscape.