This lesson's interactive features are locked, please to keep using them

Sanitizing Error Messages

Error messages are for developers, but attackers love to read them too. Imagine a ticketing site that returns a failed SQL query and stack trace in the HTTP response anytime the checkout handler crashes. The attacker now knows table names, local file paths, and which library code to probe next.

Even if the error isn't directly exploitable, it gives the attacker a handy little map of the system.

Error leaks usually happen when diagnostic details meant for developers get passed straight into an HTTP response:

// broken: renders developer diagnostics in the response
app.use((err: Error, req: Request, res: Response, _next: NextFunction) => {
  res.status(500).json({
    name: err.name,
    message: err.message,
    stack: err.stack,
  });
});

Public Responses, Private Diagnostics

The client and your logs cross different trust boundaries. Users need a low-detail failure message and a safe next step. Developers need enough server-side context to debug.

// fixed: full detail in the log, generic detail in the response
app.use((err: Error, req: Request, res: Response, _next: NextFunction) => {
  logger.error("Unhandled error", {
    method: req.method,
    path: req.path,
    message: err.message,
    stack: err.stack,
  });

  res.status(500).json({ error: "Something went wrong" });
});

The generic "Something went wrong" response is not about hiding that a failure happened. It's about keeping private diagnostics on the server, where they belong. You can often provide a safe next step, like "Please try again later" or "Contact support if the problem persists," but never include the raw stack trace.

Assignment

Bearly Secure's global error handler renders its server-side diagnostics in the response. Return a safe error page without weakening those diagnostics.

In src/errors.ts, keep logging the request method, error message, and stack trace, but record req.path so query parameters are excluded.
Send a generic error page with a 500 Internal Server Error status code and a message that tells the user the request failed and gives them a safe next step.
Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.