All 15 Error Handling questions
More in Error Handling
How would you create and use custom Error subclasses in a Node.js application to represent different categories of application-specific errors? Why doesn't Express automatically catch errors thrown inside an async route handler in versions prior to Express 5, and how do you work around this? How do you correctly propagate and handle errors from a Node.js stream, given that stream errors aren't caught by a surrounding try/catch? What is the try/catch/finally pattern's 'finally' block used for, and how does it behave with async/await? What is the difference between a validation error and a business-logic error, and how might a Node.js application handle each differently? How would you implement a global 'not found' (404) handler in Express for any route that doesn't match a defined endpoint? What is a centralized error-handling middleware pattern in Express, and what advantages does it provide over handling errors in each individual route? What is the difference between a 4xx and 5xx HTTP status code from an error-handling perspective, and how should a Node.js API decide which to return? What is error wrapping (or error chaining), and how does the Error class's 'cause' property support it in modern Node.js? How would you implement a global error boundary for an entire Node.js application to ensure no error type goes completely unhandled?
Advertisement
Node.js › Error Handling

What is the risk of exposing a raw error's stack trace in an API response, and how do you prevent it while still logging full details server-side?

Intermediate

Answer

A stack trace can reveal internal file paths, library versions, database query structure, or other implementation details that could help an attacker understand and exploit the system further -- production error handlers should log the full error (including stack trace) server-side for the engineering team, while returning only a sanitized, generic message to the actual API client, typically gated by an environment check to still show full details during local development for convenience.
app.use((err, req, res, next) => {
  logger.error(err.stack); // full details, server-side only

  const isDev = process.env.NODE_ENV !== 'production';
  res.status(500).json({
    error: 'Internal server error',
    ...(isDev && { stack: err.stack }), // only include stack trace outside production
  });
});
Real-world example A penetration test flags that a company's production API was returning full stack traces (revealing the exact file structure and an outdated library version) in error responses; the fix gates stack-trace exposure to only occur when NODE_ENV isn't 'production'.

Common follow-ups: What other information beyond a raw stack trace should be scrubbed from error responses before they reach a client?;How would you configure a logging tool to still capture this same detailed information without it ever reaching the actual HTTP response?

Security;Logging & Monitoring
All 15 Error Handling questions