Production error responses do not expose stack traces

Stack traces returned to API clients expose the internal file system paths, dependency names and versions, function call chains, and sometimes SQL queries that make up your application's internals. Attackers use this reconnaissance to identify vulnerable libraries, understand data model structure, and craft targeted exploits. CWE-209 (Generation of Error Message Containing Sensitive Information) and CWE-200 (Exposure of Sensitive Information) directly describe this class of leak. OWASP A04 (Insecure Design) and A09 (Security Logging and Monitoring Failures) both apply. AI-generated codebases are particularly prone to this: the default catch-and-return-error pattern is the path of least resistance when the model is filling in error handling.

Wrap every API route in a catch block that logs the full error internally but returns a generic message to the client. Never return err.message, err.stack, or the error object directly.

// src/app/api/example/route.ts
try {
  // ... your logic
} catch (error) {
  console.error('[API error]', error) // internal log — full detail
  return Response.json(
    { error: 'Internal Server Error' },
    { status: 500 }
  )
}

For Next.js pages, create app/error.tsx and app/global-error.tsx that render user-friendly messages without exposing the caught error. Use an error tracking service (Sentry, Datadog) to capture full traces server-side — then you get observability without client exposure.