exceptional-conditions

Exceptional Conditions Security Check (A05:2025)

What this checks

Protects against information disclosure and fail-open logic. Stack traces in API responses leak internal paths, library versions, and logic for attackers to target; swallowed exceptions and default-allow error paths grant unintended access.

Vulnerable patterns

• except Exception as e: return jsonify({"error": str(e)}), 500 — stack trace or internal message reaches client
• except: pass — silent swallow; security-relevant failure goes undetected
• except PermissionError: return allow() — fail-open grants access on error
• app.debug = True in production — full tracebacks exposed in HTTP responses
• Flask/Django default error pages that include file paths and version strings

Fix immediately

Flag the vulnerable code and explain the risk. Then suggest a fix that establishes these properties:

1. Client responses carry no internal detail. No stack trace, no file path, no library version, no raw exception message. The client gets a generic message and an opaque reference ID; the full traceback goes to a server-side log keyed by that same ID.
2. No catch block exits silently. Every except / catch / recover takes a definite action: re-raise, log, or return a controlled error. A bare except: pass or catch (_) {} is the exact bug this skill prevents.
3. Authorization failures fail closed. A PermissionError, AccessDenied, or equivalent exception in a catch block must produce a deny response — never a fall-through or default-allow. The safest pathway on ambiguity is refusal.
4. Debug / verbose-error flags are off at deployment. Framework switches like Flask app.debug=False, Spring server.error.include-stacktrace=never, Gin ReleaseMode are set explicitly, not left at their development default.

Anchor — shape, not implementation:

ref = new_uuid()
try: return handler(request)
except AuthzError:      log(ref, exc); return error_response(403, ref)
except ValidationError: log(ref, exc); return error_response(400, ref)
except Exception:       log(ref, full_traceback()); return error_response(500, ref)
# client sees: { "error": "...", "ref": ref } — no internal detail

Verification

Confirm the following properties hold (language-agnostic):

• No stack trace, file path, library version, exception message, or other internal detail reaches the client response body — only a generic message and opaque reference ID
• Every catch/except/recover block takes a definite action (re-raise, log, or return a controlled error) — no silently swallowed exceptions
• Authorization and permission failures produce a deny response (HTTP 401/403, or equivalent error return) — never a success or fall-through that grants access
• If the code configures a server or application entry point, debug/verbose-error flags are explicitly set to off (e.g. Flask app.debug=False, Spring include-stacktrace=never, Go gin.ReleaseMode). Skip this criterion for library-level code or handlers that have no configuration surface
• Every unhandled exception produces a server-side log entry containing a correlation ID (UUID or equivalent) that matches the opaque reference returned to the client

References

• CWE-388 (Error Handling)
• CWE-391 (Unchecked Error Condition)
• CWE-209 (Generation of Error Message Containing Sensitive Information)
• OWASP A05:2025 Security Misconfiguration