Not ready for a demo?
Join us for a live product tour - available every Thursday at 8am PT/11 am ET
Schedule a demo
No, I will lose this chance & potential revenue
x
x
.png)
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
Unordered list
Bold text
Emphasis
Superscript
Subscript

OWASP A10: Mishandling Exceptional Conditions is a new category introduced in the OWASP Top 10 (2025). It formalizes the security risks that arise when a system encounters states it was not designed to handle (exceptional conditions) and reacts in an unsafe, ambiguous, or permissive way, leading to potential security incidents.
The addition of A10 was driven by three major shifts in modern software development: Distributed Systems as Default: Network unreliability is now the norm, requiring robust failure handling. Abstraction Hides Failure: SDKs and cloud services often mask true failures (e.g., automatic retries, swallowing exceptions), leading developers to mistake silence for correctness. LLM-Driven Systems: The introduction of non-deterministic failure (e.g., hallucination, malformed output) by Language Models breaks traditional defensive programming assumptions.
Systems breaking (failing) is unavoidable. Mishandling an exceptional condition occurs when the system fails but does not understand how it broke, or when it reacts in an insecure way. The core issue is ambiguity. For example, leaking a stack trace in a public error message is mishandling, while logging a detailed error internally and returning a generic, safe message to the user is proper handling.
"Failing Open" is an anti-pattern where a security-critical service (like authentication or authorization) defaults to allowing access when it encounters an error (e.g., if the auth service is down). This converts an availability problem into a critical security vulnerability, effectively granting unauthorized access.
The rule is that security mechanisms must fail closed. If the authorization service is unreachable or encounters an error, the default action should be denial of access, unless there is a formally justified and highly redundant system in place.
This happens through Retry Storms in distributed systems. When a downstream service (like a database) blips or slows down, naive code often retries the failed request immediately in a tight loop. If this happens across thousands of concurrent users, the system multiplies the load on the struggling service, turning a transient issue into a full-scale, self-inflicted denial-of-service attack.
A Circuit Breaker is a design pattern that adds memory to failure handling. It monitors calls to a downstream service: If errors exceed a threshold, it opens and immediately stops all further calls to the service, converting unknown states into known "Fail Fast" errors, limiting the blast radius. After a set time, it goes half-open, allowing a single test request through to see if the service has recovered.
Partial success occurs when a multi-step workflow fails mid-pipeline, but the system returns a success status. This leaves the overall system in an inconsistent state (e.g., payment processed but item not shipped, or data corrupt/incomplete). Total failure is explicit; partial success is silent corruption that requires complex reconciliation.
LLM output should be treated as hostile, untrusted input. Unlike traditional functions, LLMs can fail non-deterministically (e.g., hallucinate, return malformed JSON, or silently truncate). Defensive measures must include: Strict schema validation (e.g., Pydantic) before use. "Refusal" detection to catch instances where the model denies the request. Robust error handling (e.g., try/except) for parsing errors (like JSONDecodeError).

.png)



Koushik M.
"Exceptional Hands-On Security Learning Platform"

Varunsainadh K.
"Practical Security Training with Real-World Labs"

Gaël Z.
"A new generation platform showing both attacks and remediations"

Nanak S.
"Best resource to learn for appsec and product security"





.png)



Koushik M.
"Exceptional Hands-On Security Learning Platform"

Varunsainadh K.
"Practical Security Training with Real-World Labs"

Gaël Z.
"A new generation platform showing both attacks and remediations"

Nanak S.
"Best resource to learn for appsec and product security"




United States11166 Fairfax Boulevard, 500, Fairfax, VA 22030
APAC
68 Circular Road, #02-01, 049422, Singapore
For Support write to help@appsecengineer.com


