error-handling-securitylisted

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/error-handling-security/SKILL.md. --> # Error-Handling Security No stack traces / SQL / paths / framework versions in client responses; generic errors out, structured errors in logs ## ALWAYS - Catch exceptions at the boundary (HTTP handler, RPC method, message consumer). Log them with full context server-side; return a sanitized error externally. - External error responses include: a stable error code, a short human-readable message, and a correlation / request ID. They never include: stack trace, SQL fragment, file path, internal hostname, framework version banner. - Log errors at the appropriate level: `ERROR` / `WARN` for actionable failures; `INFO` for expected business outcomes; `DEBUG` for diagnostic detail (and only when explicitly enabled). - Return uniform error responses across the API surface — same shape, same set of codes — so attackers can't infer behavior from error variation (e.g., login: same message and timing for "wrong username" vs "wrong password"). - Disable framework default error pages in production (`app.debug = False` / `Rails.env.production?` / `Environment=Production` / `DEBUG=False`). Replace with a 5xx page that returns only the correlation ID. - Use a centralized error-rendering helper so the sanitization rules are in one place, not duplicated. ## NEVER - Render `traceback.format_exc()`, `e.toStr