Information leakage through errors and responses¶

Information leakage occurs when a response exposes details its audience should not receive. Examples include credentials, internal paths, SQL statements, private records and diagnostic stack traces. A version string or technical detail is not automatically a severe vulnerability; assess what is disclosed, to whom, and what it enables.

This page focuses on public error responses. See information disclosure for the broader category and sensitive logging for private diagnostic handling.

Keep the public error generic¶

These alternatives are Express error middleware, registered after application routes. Their four-argument signature is significant.

Unsafe: send the internal exception to the caller.

app.use((err, req, res, next) => {
  res.status(500).json({ error: err.stack });
});

Safer: return an intentional public message.

app.use((err, req, res, next) => {
  if (res.headersSent) return next(err);
  res.status(500).json({ error: 'Internal server error' });
});

The safer handler does not serialize the exception into the response. The headers-sent branch delegates to Express's existing error handling because a response has already started. Configure production mode and review that delegated behavior too. The Express error-handling guide describes middleware ordering and production responses.

Record necessary diagnostic information through a separate, access-controlled logging path with explicit redaction. A generated correlation identifier can connect a public failure to its private event. Do not log a whole exception object automatically if it can contain passwords, tokens or customer payloads.

Check the response¶

Trigger a synthetic error whose message contains a fictional internal path. Assert that the HTTP response has the intended status and message and contains none of the marker, stack trace or exception properties. Verify that expected validation errors still return useful, deliberately designed client messages rather than an unexplained server failure.

Also inspect debug pages, JSON serializers, source maps and authorization filters. Hiding an error does not repair the underlying bug or prevent unauthorized data access. The example protects one response boundary; it does not prove the entire application is free of information disclosure.