Error Handling
V16.5.1
Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal system data such as stack traces, queries, secret keys, and tokens.
Required for Level 2 and 3
Related CAPEC™ Requirements
CAPEC™ (3.9): 116, 120, 126, 136, 137, 151, 152, 153, 160, 169, 175, 183, 184, 19, 198, 207, 21, 215, 23, 24, 250, 253, 261, 267, 28, 31, 37, 43, 50, 54, 593, 66, 664, 676, 70, 83, 88, 93
V16.5.2
Verify that the application continues to operate securely when external resource access fails, for example, by using patterns such as circuit breakers or graceful degradation.
Required for Level 2 and 3
Related CAPEC™ Requirements
CAPEC™ (3.9): 100, 114, 124, 125, 129, 130, 131, 151, 184, 207, 21, 227, 24, 25, 50, 603, 607
V16.5.3
Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail-open conditions such as processing a transaction despite errors resulting from validation logic.
Required for Level 2 and 3
Related CAPEC™ Requirements
CAPEC™ (3.9): 100, 114, 115, 116, 124, 125, 128, 129, 130, 131, 151, 152, 153, 180, 184, 207, 21, 24, 25, 26, 461, 50, 54, 554, 70, 77
V16.5.4
Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. This is both to avoid losing error details that must go to log files and to ensure that an error does not take down the entire application process, leading to a loss of availability.
Required for Level 3
Related CAPEC™ Requirements
CAPEC™ (3.9): 151, 184, 207, 21, 24, 50
Disclaimer
Credit via OWASP ASVS.For more information visit: The OWASP ASVS Project or Github respository.. OWASP ASVS is under the Creative Commons Attribution-Share Alike v4.0 license.
