T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:126- Finding
Internal Exception Messages Exposed in HTTP Responses
- Content
View full analysis
{ return c.json({ error: err.message }, 500) }) ``` A similar pattern appears in `references/routing.md`: ```ts app.onError((err, c) => { console.error(err) return c.json({ error: err.message }, 500) }) ``` The RPC documentation also exposes global exception messages: ```ts const app = new Hono() .get('/users', (c) => c.json({ users: [] })) .onError((err, c) => c.json({ error: err.message }, 500)) type AppWithErrors = ApplyGlobalResponse ``` ### Technical Analysis The examples serialize the unfiltered `Error.message` value into remotely accessible HTTP responses. Exception messages from databases, storage adapters, parsers, authentication components, and third-party services may include implementation details such as: - Database schema, query, or constraint information - Local filesystem paths - Dependency and runtime details - Internal service names and endpoints - Authentication or authorization state - Portions of malformed or sensitive input Because this Skill is documentation intended to guide generated application code, users or agents may copy this pattern into production services. The issue does not directly compromise the machine running the Skill, but it can create an information-disclosure vulnerability in applications built from the guidance. ### Attack Path 1. An attacker submits malformed input or invokes a route that triggers an unhandled exception. 2. Hono passes the exception to the global `onError` handler. 3. The handler serializes `err.message` into a JSON response. 4. The attacker collects internal implementation details from repeated error responses. 5. The disclosed details ...[truncated 549 chars]- Remediation
View remediation
{ console.error('Unhandled request error', { requestId: c.get('requestId'), error: err, }) return c.json( { error: 'Internal Server Error', requestId: c.get('requestId'), }, 500 ) }) ``` Additional hardening should include: 1. Generate and return a non-sensitive request or incident identifier for support correlation. 2. Prevent secrets, authorization headers, cookies, and request bodies from being written to ordinary logs. 3. Map expected validation and application errors to explicit sanitized responses. 4. Restrict detailed stack traces and debugging responses to local development. 5. Add tests confirming that stack traces, paths, database messages, and secrets never appear in production responses. ]]>