A Node.js API uses Express.js and returns unhandled promise rejections as JSON error responses including the error stack trace. Why is returning stack traces to clients dangerous?
- A.Stack traces reveal internal file paths, function names, library versions, and code structure that attackers use to identify vulnerable library versions (CVEs), map the codebase, and craft targeted exploits
- B.Stack traces expose the database password (from the connection string), and the browser keeps it in session storage where any injected script can read it, giving visitors a working login to the production database after one error response
- C.Stack traces trigger a second request to the logging service (Sentry), and the client then holds the API key for that service, letting visitors post forged events into the error dashboard under the developer's project name and flood the on-call rotation
- D.Stack traces slow the response (extra bytes on the wire), and clients retry the call in a loop, multiplying load on the Express process
Why A is correct