Menu

Individual skill

error-handling-security

Decide what an error tells the client and what stays server-side: no stack traces, SQL, or paths in responses, no silent suppression, and no distinction between outcomes that would reveal protected state. Use when generating HTTP, GraphQL, or RPC error handlers, exception, panic, or rescue blocks, or configuring production error pages.

dist/agent-skills/.agents/skills/error-handling-security/SKILL.md

Read pinned source

Source commit eaba88102d91df65a9aa6397e8507c315c018f5e

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Instructions only
Last checked
Nov 6, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
23
Repository last updated
Aug 14, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

<!-- Native skill bundle for agent-skills (cross-tool convention). 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

Decide what an error tells the client and what stays server-side: no stack traces, SQL, or paths in responses, no silent suppression, and no distinction between outcomes that would reveal protected state. Use when generating HTTP, GraphQL, or RPC error handlers, exception, panic, or rescue blocks, or configuring production error pages.

## ALWAYS

- Catch exceptions at the boundary — HTTP handler, RPC method, message consumer — and decide *there* what crosses to the client and what stays server-side. Record the failure with a correlation ID under `logging-security`'s policy; do not bypass its redaction rules to attach "full context", which is how request bodies, cookies and tokens end up in logs.
- Put only client-actionable information in an external error: a stable error code, a short human-readable message, and the correlation ID. Anything the caller cannot act on belongs in the log entry that shares that ID.
- Keep responses **consistent within an error class**, and make security-equivalent outcomes externally indistinguishable. Different classes may and should differ — `400 VALIDATION_FAILED`, `401`, `403`, `409`, `429` are not a finding. What must not differ is a pair of outcomes whose distinction reveals protected state: whether an account exists, whether a record the caller may not see is present. `auth-security` owns making the login paths cost the same; this rule owns what they return.
- Disable developer error pages and detailed exception rendering in every non-development environment, and route unhandled errors through the framework's production error handler. This is a wiring decision, not the same thing as an environment variable reading `production` — the setting and its name differ per framework, and `references/framework-error-pages.md` has them.
- Render every external error through one helper, so the sanitization rules live in a single place instead of being re-derived at each handler.