New Risk Category on the OWASP Top Ten: Expecting the Unexpected

With OWASP’s release of its 2025 Top Ten, enterprises have a couple of new risk categories to pay special attention to, including a brand-new category that proves, once and for all, that what you don’t know can indeed hurt you.

The new category, Mishandling of Exceptional Conditions, outlines what can go wrong when organizations aren’t prepared to prevent, detect and respond to unusual or unpredictable situations. According to OWASP, this vulnerability can trigger when an application doesn’t prevent something unusual from occurring, fails to identify a problem when it crops up and/or responds poorly or not at all when an unexpected situation rears its head. 

The idea that enterprises need to be ready for what they didn’t see coming reflects the reality of today’s highly distributed, interconnected systems. And it’s not like OWASP is talking about problems that are unheard of—the Mishandling of Exceptional Circumstances contains 24 Common Weakness Enumerations (CWEs). It’s just that those CWEs, which involve improper error handling, failure to open events, logical errors and other scenarios, can occur under abnormal conditions. This can result, for instance, from inadequate input validation, high-level errors in handling functions and the inconsistent (or non-existent) handling of exceptions. As OWASP states, “Any time an application is unsure of its next instruction, an exceptional condition has been mishandled.”

Those exceptional circumstances can cause systems to fall into an unpredictable state, resulting in system crashes, unexpected behavior and long-lasting security vulnerabilities. The key to preventing this kind of disruption is to, essentially, expect the worst and plan to be prepared for whenever the unexpected happens.

[WATCH VIDEO]

Exceptional Circumstances and the Evolution of the Top Ten

The makeup of the quadrennial Top Ten list of the most serious risks to web application security has been fairly stable through the years, with some categories moving around the list and maybe one or two additions every four years. The 2025 iteration has two new entries, including Mishandling of Exceptional Conditions coming in at No. 10. The other, Software Supply Chain Failures, which sits at No. 3, is an expansion of an earlier category, Vulnerable and Outdated Components (No. 6 in 2021), that now includes a broad range software compromises. (For those keeping score, Broken Access Control still rules the roost as the No. 1 risk). 

The exceptional conditions that constitute the newest category can create a host of vulnerabilities, from logic bugs to overflows, and fraudulent transactions to issues with memory, timing, authentication, authorization and other factors. These types of vulnerabilities can impact the confidentiality, availability and integrity of a system or its data. They allow an attacker to manipulate an application's flawed error handling, for example, to exploit the vulnerability, OWASP said. 

One example of failing to handle unexpected conditions is when an application identifies exceptions while files are being uploaded during a denial-of-service attack, but then fails to release resources afterward. When that happens, resources remain locked or unavailable, resulting in resource exhaustion. If an attacker intrudes on a multi-step financial transaction, a system that doesn’t roll back the transaction once an error is detected could allow the attacker to drain the user’s account. If an error is detected part of the way through a transaction, it’s very important to “fail closed”—that is, roll back the entire transaction and start over. Trying to recover a transaction in midstream can create unrecoverable mistakes.

Fail Closed vs. Fail Open

So, what’s the difference between these two actions? Let’s clarify:

Fail Open: If a system “fails open,” it continues to operate, or remains “open” when something goes wrong. This is useful when keeping things running is very important, but it can be risky for security.

Fail Closed: If a system “fails closed,” it automatically shuts down or becomes secure when there’s a problem. This is safer from a security perspective because it helps prevent unauthorized access.

Handling Unforeseen Errors

Preventing this kind of risk starts with planning for the unknown. And that involves being able to detect any possible system error when it occurs and taking steps to solve the problem. You need to be able to properly inform the user (without revealing critical information to the attacker), log the event and, if necessary, issue an alert. 

Here’s an example of the disclosure of a SQL query error, along with the site installation path, that can be used to identify an injection point:

Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:\app\index_new.php on line 188

A system ideally would have a global exception handler in place to catch overlooked errors, along with features such as monitoring or observability tooling, or a feature that detects repeated errors or patterns that could flag an ongoing attack. This can help defend against attacks that are intended to take advantage of any weaknesses the enterprise may have in handling errors.

For a standard Java web application, for instance, a global error handler can be configured at the web.xml deployment descriptor level—in this case, a configuration used from Servlet specification version 2.5 and above.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
‍
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

‍‍version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>
‍

This little block of code tells a Java web application what to do when something goes wrong behind the scenes. Instead of showing users a confusing error message or a blank screen, it quietly catches the problem and sends them to a custom error page. In this case, that page would be error.jsp.

Because it’s set to handle the general java.lang.Exception types, it acts as a master error handler for the whole app. That means no matter where an error happens, users will be redirected to the same friendly, consistent error page instead of seeing raw technical details.

Preventing the Unexpected

Ideally, organizations should work to prevent—as much as possible—exceptional conditions from even occurring. Implementing rate limiting, resource quotas, throttling and other limits can help against denial-of-service and brute force attacks, for example. You may want to identify identical repeated errors and include them only as statistics, so they don’t interfere with automated logging and monitoring. A system should also include:

Strict input validation, to ensure that only properly formed and sanitized data is entering the workflow. It should be early in the data flow, ideally as soon as any data is received.

Error handling best practices, to catch errors right where they happen. They should be dealt with efficiently: Tell users clearly that they must keep a log and send alerts if needed. A global error handler is also ideal to catch anything that was missed. 

General transaction safety, is also a must. Always “fail closed”: if something goes wrong, roll back the entire transaction. And don’t try to fix a transaction halfway—it can cause bigger problems.

Centralized logging, monitoring and alerting, along with a global exception handler, which allows for quick investigation of incidents and a uniform process of handling events, while also making it easier to meet compliance requirements.

Threat modeling and/or secure design review, performed in the design phase of projects.

Code review or static analysis, as well as stress, performance and penetration testing performed on the final system.

Mishandling of Exceptional Conditions may be a new category, but it involves some basic principles of cybersecurity and emphasizes why enterprises need to be prepared for what they aren’t necessarily anticipating. You may not know what form exceptional conditions will take, but you know they will happen. The key is in being prepared to handle all of them in the same way, which will make it easier to detect and respond to those conditions when the inevitable crops up. 

Note to SCW Trust Score™ Users:

As we update our Learning Platform content to align with the OWASP Top 10 2025 standard, you may observe minor adjustments in the Trust Score for your Full Stack developers. Please reach out to your Customer Success representative if you have any questions or require support.