Mishandling of Exceptional Conditions: Planning for When Things Go Wrong

Mishandling of Exceptional Conditions is a new category in the OWASP Top 10:2025 and the final category in this set of PWPA study notes.

My starting question is simple: what does the application do when a step does not complete as expected?

A dependency can time out. Input can be missing. Storage can fill up. An operation can finish only partly, or finish successfully without the caller receiving confirmation. Those conditions need to be considered in the application's behavior.

A failed check must have a safe outcome

Imagine a hypothetical document service that asks another component whether a user may download a private file.

If the permission check times out, the service has not established that access is allowed. Treating that error as permission would create a route around the control.

For that protected operation, the safe outcome is to withhold the download and report that the request could not be completed. This is an example of failing closed: a failed security check does not turn into authorization. OWASP's A10 overview includes this kind of failure alongside error handling and unexpected application states.

Handle an error where there is enough context

Some failures can be handled meaningfully close to the operation. A function may be able to reject invalid input, release a resource, or return a clear failure to its caller.

A shared error-handling approach helps keep responses and logging consistent. A global handler can provide a final boundary for unexpected errors, but it cannot automatically repair the state of every interrupted operation.

Catching an exception and continuing without resolving the problem can leave the application in an unsafe state. Microsoft's exception-handling guidance reinforces the need to catch errors when recovery is possible and to clean up resources reliably.

Tell the user what they need to know

A user may need to know that an operation failed and how to identify it when asking for help. They generally do not need the database query, internal file paths, or full stack trace.

The application can return an appropriate error response and a reference identifier while keeping necessary diagnostic details in protected logs. Those logs still need to exclude secrets and unnecessary personal data. The OWASP Error Handling Cheat Sheet explains the separation between client-facing responses and internal diagnostics.

Partial success makes recovery harder

Consider a hypothetical booking operation that reserves a place and then records confirmation. If the second step fails, the system needs a defined way to avoid leaving an unexplained reservation behind.

When related database changes belong in one transaction, atomicity can help keep them consistent. Work that crosses services may need additional coordination or compensating actions.

A timeout introduces another difficulty: the caller may not know whether an operation took effect. Repeating it immediately can create a duplicate. Recovery therefore needs to account for the actual state and whether the operation is safe to repeat.

Idempotency is useful here. An idempotent operation can be repeated without applying its intended effect more than once. Retries also need limits and suitable delays so that a struggling dependency is not flooded with more work. Microsoft's Retry pattern guidance discusses these trade-offs.

Resources need limits and cleanup

A failed upload or interrupted request can leave open files, connections, or other resources behind if cleanup is incomplete. Repeating the failure may eventually exhaust what the service has available.

Appropriate request limits, timeouts, quotas, and resource cleanup help contain the problem. Tests should include failure paths as well as normal operation: unavailable dependencies, malformed input, interrupted work, and exhausted capacity.

Questions for my notes

What happens if a security check cannot complete?
Can an error leave partially updated state?
Is the result known before the operation is retried?
Are resources released on unsuccessful paths?
What does the user see, and what is recorded internally?
Which repeated failures should trigger investigation?

Looking back at the series

The ten categories give me different ways to examine the same application. Who can act? What data and code can be trusted? Which assumptions shape the design? How will the team recognize a problem, and how will the system behave when something fails?

That is the value I am taking from this reading. The Top 10 provides a structure for asking better questions, while the detailed guidance helps turn each question into something that can be designed, implemented, and tested.

Sources and further reading