500 pages do not expose internal details

Rendering error.message or error.stack to the DOM or returning it in an API JSON response exposes your internal architecture to anyone who triggers a 500 — framework versions, file system paths, database error codes, and third-party service identifiers are all visible in unfiltered stack traces. OWASP A05 (Security Misconfiguration) and CWE-209 (Generation of Error Message Containing Sensitive Information) classify this as an active information-disclosure vulnerability, not merely a cosmetic issue. Attackers routinely trigger intentional errors to enumerate your stack before targeting known CVEs. CWE-215 (Insertion of Sensitive Information Into Debugging Code) further applies when dev-mode conditionals are left in production builds.

Replace all {error.message} or {error.stack} renders with a static user-safe message. Log internally, never to the DOM.

// app/error.tsx — safe version
'use client'
export default function Error({ error, reset }: { error: Error; reset: () => void }) {
  useEffect(() => { reportError(error) }, [error])
  return (
    <div>
      <h2>Something went wrong</h2>
      <p>We've been notified. Please try again.</p>
      <button onClick={() => reset()}>Try again</button>
    </div>
  )
}

For API routes:

} catch (error) {
  console.error('[API Error]', error) // server-side only
  return NextResponse.json({ error: 'Internal server error' }, { status: 500 })
}

Verify with NODE_ENV=production by triggering a deliberate error and inspecting both the response body and rendered DOM for any technical details.