GuideAdvisoryCybersecurityIT

OWASP A10:2025: make custom apps fail closed when errors, timeouts and partial transactions occur

OWASP’s 2025 Top 10 adds Mishandling of Exceptional Conditions, covering poor error handling, logic errors and failing open. Its guidance is to catch errors where they occur, roll back interrupted transactions, limit resources and centralize handling.

Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.
DSE visual intelligenceCyber defenseGuide · 2 min read
Executive summary

What you need to know

OWASP’s 2025 Top 10 adds Mishandling of Exceptional Conditions, covering poor error handling, logic errors and failing open. Its guidance is to catch errors where they occur, roll back interrupted transactions, limit resources and centralize handling.

Potentially affected

Custom web applications, APIs, payment or ordering workflows, integrations and background jobs, especially multi-step transactions and code that calls databases, files or external services.

DSE recommendation

DSE recommends adding exceptional-condition handling to the security requirements and test plan of every custom-software project.

OWASP’s 2025 Top 10 adds Mishandling of Exceptional Conditions, covering poor error handling, logic errors and failing open. Its guidance is to catch errors where they occur, roll back interrupted transactions, limit resources and centralize handling.

Source facts

OWASP introduces Mishandling of Exceptional Conditions as a new category for 2025. It maps 24 CWEs and focuses on improper error handling, logical errors and failing open; notable entries include CWE-209, error messages containing sensitive information, and CWE-636, not failing securely.

OWASP’s prevention guidance is to catch errors where they occur and handle them meaningfully, keep a global exception handler for anything missed, and, when a transaction is interrupted part way through, roll back every part and start again, which it calls failing closed. It also recommends rate limiting, resource quotas and throttling, strict input validation, and centralized error handling, logging, monitoring and alerting.

Its example scenarios include resource exhaustion when exceptions during uploads leave resources locked, database errors that reveal full system details to an attacker, and a multi-step financial transaction that is not rolled back after an interruption.

Applicability

Use this for application code in any language and for the design of integrations and workflows. OWASP recommends handling exceptional conditions the same way across an organization to make review and audit easier.

DSE recommendation

DSE recommends adding exceptional-condition handling to the security requirements and test plan of every custom-software project. Require a single error-handling approach per application, generic error messages to users with detailed logs kept server-side, explicit rollback for each multi-step transaction, and limits on uploads, requests and resource use; include these items in code review and in the contractor’s test report.

Verification

Test by forcing failures: interrupt a multi-step transaction mid-way, make a database or upstream API unavailable, send malformed and missing parameters, and exhaust upload limits. Confirm that no partial transaction is committed, users see no stack traces or system details, resources are released, and the events reach monitoring.

Official reference

OWASP Top 10:2025 — A10:2025 Mishandling of Exceptional Conditions. Reviewed October 18, 2026.

Primary reference

Review the official source

OWASP Top 10:2025 — A10:2025 Mishandling of Exceptional Conditions · Verified October 18, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE