CWE-756 covers products that do not return custom error pages to the user, which can expose sensitive information. The default page that a web server or framework produces was written for developers, not for strangers on the internet.
Every web application and web server is in scope. It is a small weakness that costs very little to fix.
How it happens
A request fails and the server answers with its stock page. That page can include a stack trace, a framework name and version, file paths or a database error. Nobody decided to publish that. Nobody decided against it either.
MITRE lists CVE-2023-27998, an analytics platform that had no custom error page and allowed access to sensitive information.
What an attacker gains
The consequence in the record is confidentiality. Attackers use the extra detail in a default page to aim attacks at the framework, database or other resources behind the app. An error that names the database engine saves them a round of guessing.
How to find it
Trigger errors on purpose and read what comes back. Request a missing path, send a malformed body, break a required parameter, and use a wrong method. A dynamic scan of the running app does the same at scale.
Click through it at your own pace, or open it full screen.
How to fix it
Register a global error handler that returns a short generic message and a request ID, and writes the detail to a log. In Express it looks like this.
// Fix: generic response, details stay in the server log
app.use((err, req, res, next) => {
console.error(req.id, err);
res.status(500).send("Something went wrong. Reference: " + req.id);
});
Do the same for 404 and 403 at the web server layer, and turn off any debug mode in production.
Quick check
Where should the full error detail go?
Into your server logs, tied to a request ID that the user can quote to support.
