mediumCWE-209A05:2021

Stack Traces Exposed to User

Returning stack traces or internal error details in API responses reveals your file structure, library versions, and code paths to attackers.

How It Works

A stack trace tells an attacker which libraries you're using, their versions, the internal file structure of your server, and which lines of code failed. This makes targeted attacks significantly easier — they can look up CVEs for your exact library versions and craft input to exploit specific code paths.

Vulnerable Code
// BAD: raw error sent to client includes stack trace
app.use((err, req, res, next) => {
  res.status(500).json({
    error: err.message,
    stack: err.stack,  // exposes /home/user/project/src/routes/auth.ts:42
    details: err       // may include query, config, or other internals
  });
});
Secure Code
// GOOD: generic error to client, full details only in server logs
app.use((err, req, res, next) => {
  console.error({ error: err.message, stack: err.stack, userId: req.user?.id });
  res.status(500).json({
    error: 'Something went wrong. Please try again.', // nothing internal
    requestId: req.id  // so the user can report it and you can find it in logs
  });
});

Real-World Example

OWASP identifies information exposure through error messages as a persistent vulnerability. Penetration testers routinely use stack traces from error responses to identify exploitable library versions and internal application structure.

How to Prevent It

  • Return generic error messages to clients — never raw exception messages or stack traces
  • Log full error details server-side with a request ID that the user can reference
  • Set NODE_ENV=production to suppress stack traces in many frameworks automatically
  • Use a global error handler that sanitizes all error responses before sending

Affected Technologies

Node.js

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities