Prevent stack trace exposure in production error responses
SkillSecuritystack-trace-exposure is a Claude skill for security reviews of error handling. It guides an agent through checking whether production API error responses leak stack traces, file paths, or internal details that attackers could use to identify framework versions and known CVEs.
Available today. Use it from your connected AI after setup.
No other account needed.
Have an AI agent environment that supports loading skills.
Then ask your AI: use the Prevent stack trace exposure in production error responses skill
What your AI can do with it
- Check whether production API error responses include stack traces, file paths, or internal
- Review error handlers, catch blocks, and API response code for serialised error.stack, raw
- Guide implementation of a central error handler that logs details server-side and returns
- Explain what stack traces reveal and how attackers use them to find and exploit vulnerabil
- Recommend correlation IDs so support teams can match client-visible errors to server logs
Getting started
- Have an AI agent environment that supports loading skills.
- Add the stack-trace-exposure skill files to the agent's skills location.
- Open the skill's references/rule.md for full implementation details, code examples, and framework-specific guidance.
- Ask the agent to review error handling middleware, API route handlers, or server responses using the skill.
What this skill tells your AI
The instructions your AI receives, as published by thedaviddias/front-end-checklist in skills/stack-trace-exposure/SKILL.md and read by ahel’s review.
Stack traces reveal file paths, function names, library versions, and sometimes database schema or configuration details. An attacker uses this information to identify the exact version of a framework or ORM, look up known CVEs for that version, and craft a targeted exploit. OWASP lists "Security Logging and Monitoring Failures" (A09) as a top-10 risk partly because organisations often expose this information without realising it.
Quick Reference
- Never return raw error objects or stack traces in API responses
- Log full error details server-side; send only a generic message to the client
- Use a central error handler to ensure consistent sanitisation across all routes
- Assign correlation IDs so support teams can match client-visible errors to server logs
Check
Check whether production API error responses include stack traces, file paths, or internal implementation details.
Fix
Implement a central error handler that logs full details server-side and returns only a sanitised, generic error message to the client.
Explain
Explain what information stack traces reveal and how attackers use that information to identify and exploit vulnerabilities.
Code Review
Review error handlers, catch blocks, and API response code. Flag any location where error.stack, error.message (raw), or internal paths are serialised directly into a response body.
For full implementation details, code examples, and framework-specific guidance,
see references/rule.md.
Rule page: https://frontendchecklist.io/en/rules/security/stack-trace-exposure
Signals
- GitHub stars
- 74k
- Forks
- 7k
- Last commit
- Aug 2026
Questions
- When should this skill be used?
- Use it when reviewing error handling middleware, API route handlers, or server responses for security-sensitive information disclosure.
- What does the check look for?
- Whether production API error responses include stack traces, file paths, or internal implementation details.
- What is the recommended fix?
- Implement a central error handler that logs full details server-side and returns only a sanitised, generic error message to the client.
Advanced
- Item type
- skill
- Key
stack-trace-exposure- Source
- github.com/thedaviddias/front-end-checklist