Stack Traces and Internal Details in Error Responses

An error response that includes a stack trace, a database query, file paths or software versions gives an attacker a description of the system to plan an attack with. A public error must say what the client needs to fix its request, and no more; the internal detail belongs in the server's logs.

Picture a penetration test report, the findings of a hired security tester, quoting a stack trace returned by a public endpoint. It names the framework and its version, the ORM, the database's table and column names, and a file path on the server. The tester looked up the version's known vulnerabilities in minutes.

The symptom. 500 responses whose bodies run to dozens of lines, with words such as Exception, at com.example, SELECT or /var/www.

500 Internal Server Error
PSQLException: column "emial" does not exist
  SELECT id, emial FROM customers WHERE id = 7
  at com.example.CustomerRepo.find(CustomerRepo.java:42)
Server: Apache-Tomcat/9.0.1

{"type": "about:blank",
 "title": "Internal Server Error",
 "status": 500,
 "instance": "urn:request:4f9a1c"}

Why it happens. Frameworks show detailed error pages in development, which is what developers want there, and the setting is carried into production. Or a handler catches an exception and returns its message, which happens to contain the SQL.

What it costs. Table and column names help an attacker shape a SQL injection. Versions point at published vulnerabilities. Paths and host names describe the network. None of it helps a legitimate client, which cannot fix a server bug.

What to do. Return a generic body for every 5xx, with a request ID, a correlation id that also appears in the logs, so support can find the full detail. Log the stack trace server side. Turn off development error pages in production, and test that a forced error returns the safe shape. For 4xx errors, say which field was wrong and why, which is information the client sent in the first place.