The Open Worldwide Application Security Project (OWASP) has just dropped the 2025 release candidate of its famous rating — OWASP Top 10. Last time it was updated was in 2021, and given that OWASP Top 10 is the main benchmark for web application security, this release is a big deal. So, let’s analyze what has changed in OWASP Top 10 2025 compared to Top 10 2021.

What Has Changed in OWASP Top 10 2025 

Most issue types remained as they were, with many occupying the same place where they were in 2021. However, there are also major shifts and two new categories.

Source: owasp.org

First, Software Supply Chain Failures is now its own top-level risk, which sits near the top of the list. It no longer talks only about outdated libraries. It covers the entire path from a developer’s machine, through source control and build tools, into artifact registries and deployment pipelines. The message is simple: attackers are happy to compromise your app before it even reaches production.

Second, Mishandling of Exceptional Conditions is a new category at the bottom of the list. This covers bad error handling, systems that “fail open” when something goes wrong, and edge cases that leave data or state in a broken condition. These are not rare corner cases — many outages and data leaks start as a small unhandled exception that cascades.

There are also some quieter changes. Security misconfiguration moves up to the second spot, which reflects how heavily modern apps rely on complex configuration in frameworks, cloud platforms, containers, and managed services. 

Server-side request forgery is no longer a separate category and is now treated as a form of broken access control. Logging and alerting is renamed to stress that alerts and response are just as important as collecting logs.

What This Means for Protecting Web Applications

For web application security teams, the OWASP Top Ten 2025 list points to a few practical priorities.

1. Know What You Actually Have

Misconfiguration is a growing problem partly because many teams do not know all of the systems they are exposing to the internet. The single most important foundation is thorough asset discovery.

Security teams should maintain a living inventory of all external web assets. This inventory should include applications, APIs, subdomains, storage endpoints, admin panels, and third-party portals. It should pull from DNS, cloud accounts, load balancers, web gateways, and external scanning tools. It should be updated on a regular basis, not only during annual audits. Sounds too complicated? Fortunately, there are many asset discovery tools that can do that for you, many of them are completely free.

Once you know what you have, you can review configurations for each asset type and remove defaults, test switches, debug endpoints, and open management ports. Configuration should be stored as code where possible, so that changes are visible, reviewed, and consistent across environments.

2. Treat Access Control as a Design Problem, Not a Patch

Broken access control remains the most serious risk because it is often baked into the design of an application.

It helps to use a clear, central way to decide who can do what. Every route, operation, and resource should have an explicit rule. When something is unclear, the system should deny the request by default rather than allow it. This is especially important for internal and machine-to-machine calls, which are easy to overlook.

Since server-side request forgery is now treated as an access control issue, teams should also limit outgoing connections. Applications should only be able to call approved internal and external endpoints. Requests that use user-supplied URLs should be validated carefully against these limits.

3. Secure the Software Supply Chain End to End

With “Software Supply Chain Failures” elevated, the bar is now higher than “run a vulnerability scanner on your dependencies occasionally.”

Teams should keep a clear, automated list of the components that make up each application. This list is often called a software bill of materials. It should include both direct and indirect dependencies. The list should be produced during the build, stored with the artifacts, and checked on every build and deployment.

Build and deployment systems deserve the same care as production. Access to repositories, continuous integration tools, and registries should use strong authentication and separate roles. Builds should produce signed artifacts, and only these trusted artifacts should be allowed into production. Developer machines and extensions should be patched, protected, and monitored, since they are now a common entry point for supply chain attacks.

4. Handle Errors and Edge Cases Safely

The new category on mishandling exceptional conditions reinforces something many teams learn the hard way. The way an application behaves when things go wrong is just as important as its normal behavior.

Applications should have predictable error handling. Common problems should be handled close to where they occur, and there should be a global safety net for anything that slips through. The user should receive a simple error message, while the system logs detailed information on the server side. When something is uncertain about identity, authorization, or transaction state, the system should deny the operation or roll it back, not let it pass.

Monitoring and alerting should treat repeated errors and strange patterns as first-class signals. This connects strongly with the updated logging and alerting category. A log that no one reads is not much better than no log at all.

5. Don’t Forget the Basics: Input, Cryptography, Authentication

Although some categories move down slightly, they remain critical.

Injection is still a problem whenever user input is combined with queries or commands without proper separation. Applications should use parameterized queries, safe templates, and built-in encoding functions for each context, such as HTML or JavaScript output.

Cryptographic failures are less about math and more about misuse. Teams should rely on well maintained platform libraries and cloud key management services. They should avoid writing their own cryptography routines and storing secrets in code or configuration files.

Authentication issues are easier to manage if they rely on proven frameworks and identity providers. Sessions and tokens should be short lived and protected with secure cookies and transport encryption. Sensitive actions and admin functions should use extra checks such as multi-factor authentication and rate limiting.

A Realistic Action Plan for 2025

If you want a plan that reflects the priorities from the new Top 10 without turning it into another slide deck, you can focus on a few steps:

1. Build and maintain a reliable inventory of all your web-facing assets and key supply chain components. 
2. Design access control centrally and enforce a default-deny approach, including for outbound calls. 
3. Treat build and deployment systems as sensitive targets and protect them accordingly. 
4. Introduce consistent, safe error handling and connect it to meaningful alerts. 
5. Finally, keep strengthening input handling, encryption, and sign-in flows using well supported tools.

If application security teams do these things, they will be closely aligned with the 2025 OWASP Top 10 and better prepared for how web applications are attacked today.