Systems that fail open, leak details in errors or leave half-finished transactions behind can be pushed into unsafe states by attackers who trigger errors on purpose. The category is new in 2025.
- Catch errors where they occur and handle them deliberately, with a global exception handler as a backstop.
- Fail closed: roll back partially completed transactions instead of continuing in an unknown state.
- Return generic messages to users, and log and alert on unusual error patterns.
- Limit resources with quotas, timeouts and rate limits so that unexpected input cannot exhaust the system.
Guides on this site
Handle failures without leaking internals or weakening controls
Give callers a useful, bounded response while preserving protected diagnostic evidence and safe application state.
Bound background jobs and make retries safe
Keep queues, workers and paid dependencies within a defined budget when clients retry, cancel or disappear.
Find, fix and contain memory-safety bugs in C and C++
Recognize out-of-bounds access, use after free, NULL dereference and integer overflow in C and C++, fix them with checked lengths and single ownership, harden release builds, catch the rest with sanitizers and fuzzing, and plan new code in a memory-safe language.
Practice
- Buffer over-read lab: Stop a heartbeat over-read · Browser lab
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.