OWASP Top 10 A10 Guide: Mishandling of Exceptional Conditions (2025): Failing Safely Under Error

When an application hits a condition its developers did not plan for, it often does something insecure: it leaks internals, fails open, leaves a transaction half done or falls over. A10:2025 Mishandling of Exceptional Conditions is the new OWASP Top 10 category for these failures, and it collects 24 CWEs that earlier editions scattered under code quality. This guide explains what OWASP includes, how ASVS 5.0 turns it into testable requirements, where authentication and machine credential handling fail under error, and how to implement, test and evidence a fail-secure error model. It goes deeper than the OWASP Top 10 Guide and is written for developers, application security engineers and architects who review error paths.

Key takeaways

• A new category for 2025. OWASP added A10 to replace broad code quality CWEs with a focused set of 24 covering how software prevents, detects and responds to unusual conditions.
• Three ways to fail. OWASP says an application mishandles an exceptional condition when it does not prevent it, does not recognise it as it happens, or responds poorly or not at all afterwards.
• Fail closed is the rule. CWE-636 Not Failing Securely ('Failing Open') and ASVS V16.5.3 require that an error in a security check denies the action rather than allowing it.
• Error messages are reconnaissance. Stack traces, SQL errors and framework versions returned to clients (CWE-209, CWE-550) help attackers refine injection and target known flaws.
• Handle locally, catch globally. OWASP asks for errors to be handled where they occur, with a global "last resort" handler (ASVS V16.5.4) as the safety net, and one consistent mechanism across the organisation.

What it is and who it applies to

OWASP defines the category as software failing to prevent, detect or respond to unusual and unpredictable situations, leading to crashes, unexpected behaviour and vulnerabilities. Its listed causes are missing or incomplete input validation, error handling that happens late and at a high level instead of at the point of failure, unexpected environmental states such as memory, privilege or network problems, inconsistent exception handling and unhandled exceptions. OWASP's own shorthand: any time an application is unsure of its next step, an exceptional condition has been mishandled.

The consequences reach all three security properties: logic bugs, overflows, race conditions, fraudulent transactions and failures in memory, state, resources, timing, authentication and authorisation. The category therefore applies to every team writing server-side code, APIs, background workers and integrations, and to security engineers who design authentication and authorisation libraries, because those are the components where failing open is most damaging.

Structure and key requirements

The 24 CWEs fall into four practical groups. Grouping them helps decide which tool or review technique finds each one.

What OWASP asks you to do

• Plan for failure: assume things will go wrong, and handle errors where they occur with a meaningful recovery: an understandable error to the user, a log entry and an alert when justified.
• Global handler as safety net: catch anything missed in one place, log it and return a generic response.
• Fail closed on transactions: roll back failed transactions completely and restart, because partial recovery often causes unrecoverable errors.
• Apply limits: rate limits, resource quotas and throttling, because unlimited resources lead to denial of service, brute-force success and high cloud costs. See the Rate Limiting and API Abuse Guide.
• Summarise repeated errors: above a set rate, report identical errors as statistics so logging and monitoring keep working.
• Validate strictly and centralise: strict input validation and one consistent error handling, logging, monitoring and alerting mechanism per application, ideally organisation wide.
• Build it into the lifecycle: security requirements, threat modelling, secure design review, code review or static analysis, and stress, performance and penetration testing.

ASVS 5.0 V16.5 Error Handling

For API responses, the OWASP Error Handling Cheat Sheet recommends a consistent problem document. RFC 9457 Problem Details for HTTP APIs (which obsoletes RFC 7807) defines the application/problem+json media type with type, status, title, detail and instance members, and its security considerations warn against exposing implementation internals such as stack dumps.

Identity and NHI requirements

Authentication and authorisation code is where exceptional conditions do the most harm, because the safe answer to "I am not sure" is always "deny". The same applies to code that fetches or uses machine credentials.

• Never echo credentials in errors: ASVS V16.5.1 names secret keys and tokens explicitly. Connection failures that print the full connection string, and HTTP client exceptions that include the Authorization header, are common sources. See the OWASP NHI Top 10 NHI2 Secret Leakage Guide.
• No privilege escalation on retry: a workload that catches an access denied error and retries with a broader identity turns an exception into a privilege escalation path. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
• Distinguish client and server errors: the cheat sheet recommends 4xx for client-caused problems such as unauthorised access and 5xx only for failures the server cannot handle, with 5xx rates monitored. A spike in 5xx from token validation is a detection signal, not just an availability issue. See the OWASP Top 10 A09 Guide.

Implementation steps

1. Set the error model: write a short standard covering exception types, which layer handles what, the generic client response (problem document format), the log event for each error class and the rule that security checks fail closed.
2. Install the global handler first: configure the framework's last resort handler so no stack trace can reach a client. Examples from the OWASP cheat sheet: an <error-page> for java.lang.Exception in web.xml; a @RestControllerAdvice class returning ProblemDetail in Spring; UseExceptionHandler with UseDeveloperExceptionPage only in development for ASP.NET Core; customErrors mode="RemoteOnly" for ASP.NET on .NET Framework. Test in a staging environment by forcing an exception, then promote.
3. Audit security-critical paths: review every catch block in authentication, authorisation, payment and data export code. Look for catch-all handlers (CWE-396), empty catches (CWE-390), ignored return values (CWE-252) and default branches that allow (CWE-478, CWE-636).
4. Make transactions atomic: wrap multi-step state changes in a transaction or a saga with compensating actions, so a failure mid-way rolls back fully. Add idempotency keys to prevent duplicate execution after retries.
5. Add limits and resilience patterns: timeouts on every outbound call, circuit breakers for dependencies (ASVS V16.5.2), resource quotas, and release of file handles, connections and locks in finally or equivalent constructs (CWE-460).
6. Enable static rules in CI: turn on SAST rules for the A10 CWEs in audit mode first, review the findings, then make new high-severity findings block merges. See the Secure Code Review Guide.
7. Test the unhappy path: fuzz parsers and API inputs, run negative tests with missing, extra and malformed parameters, inject dependency failures (timeouts, refused connections, expired certificates) and stress test resource limits. See the Fuzzing Guide.
8. Roll out in stages: change error handling behind feature flags or deployment rings and watch error rates and support tickets. Roll back by reverting the flag, never by re-enabling detailed errors in production.

Small versus large organisations: a small team gets most of the value from a framework global handler, a problem details response and a code review checklist. A larger organisation should provide a shared error handling library per language, SAST rules tuned to it, and a resilience testing programme that includes dependency failure injection.

The July 2024 CrowdStrike Channel File 291 incident is a widely studied example of an unanticipated condition: CrowdStrike's root cause analysis describes a definition expecting 21 input fields while the sensor supplied 20, and a content interpreter with no runtime bounds check, so the resulting out-of-bounds read crashed Windows hosts. Its fixes were the A10 list in practice: compile-time and runtime validation, tests that exercised every field and staged deployment with rollback. See the Third-Party Concentration Risk Guide.

Evidence and assessment

Metrics that show it is working

• Unhandled exception rate: exceptions reaching the global handler per million requests, trending down as local handling improves.
• Error disclosure findings: DAST or penetration test findings for verbose errors (CWE-209, CWE-550) per release.
• Open A10 SAST findings: count and age of findings mapped to the 24 CWEs on critical services.
• Fail-closed test pass rate: share of security dependencies with an automated test proving they deny on failure.
• 5xx ratio by endpoint: server error rates, with alerts on sudden rises that may indicate probing.

Mapping to other frameworks

Common pitfalls

• Catch everything, do nothing: catch (Exception e) {} in an authorisation helper turns every failure into a pass. CWE-390 and CWE-396 are the usual SAST hits.
• Developer error pages in production: framework debug pages left on after a deployment expose stack traces, paths and versions. Tie debug mode to an environment variable that production cannot set.
• Availability over security in auth: teams under outage pressure add "allow if the policy service is down" logic and never remove it.
• Partial transactions: a debit committed before a credit fails, with no compensation, is the OWASP financial state corruption scenario and a race condition target.
• Resource leaks on exception paths: OWASP's upload example: exceptions are caught but locks and handles are never released, until the service stops.
• Testing only the happy path: as the CrowdStrike root cause analysis showed, tests that never exercise an unusual input value miss the fault that later matters.

Practitioner checklist

• Publish an error handling standard with a fail-closed rule for every security check.
• Configure a global last resort handler in every application and verify no stack traces reach clients.
• Return RFC 9457 problem documents with generic detail for unexpected errors.
• Review all catch blocks in authentication, authorisation, payment and export code.
• Make multi-step state changes atomic, with rollback or compensation and idempotency keys.
• Set timeouts, circuit breakers and quotas on every external dependency.
• Ensure credential retrieval failures stop the workload rather than fall back to a default secret.
• Enable SAST rules for the A10 CWEs and gate new high-severity findings.
• Fuzz inputs and inject dependency failures in CI or pre-release testing.
• Log and alert on unhandled exceptions and 5xx spikes.

Standards and references

• OWASP: A10:2025 Mishandling of Exceptional Conditions
• OWASP: Application Security Verification Standard 5.0
• OWASP: Error Handling Cheat Sheet
• IETF: RFC 9457 Problem Details for HTTP APIs
• MITRE: CWE-636 Not Failing Securely ('Failing Open')
• NIST: SP 800-53 Rev. 5
• CrowdStrike: Channel File 291 Incident Root Cause Analysis

Related NHI Mgmt Group resources: OWASP Top 10 Guide · OWASP Top 10 A09 Guide · Secure Error Handling and Logging Guide · Secure Code Review Guide · Fuzzing Guide