Exposed information: what your code gives away

Why this area matters

Information exposure (CWE-200, CWE-209, CWE-215) is rarely the breach itself, but it is how breaches get planned: a stack trace names the framework version, a debug route lists environment variables, a served .git directory hands over the source, and a secret committed years ago is still sitting in history.

Scanners flag these individually. Whether they matter depends on whether the route is reachable in production, whether the error handler is dev-only, and whether a leaked value is still valid. The review step checks each of those.

What goes wrong in real applications

• Debug and diagnostic endpoints

  Routes that dump configuration, environment variables or internal state, left reachable in production, give outsiders a map of your system and sometimes its credentials.

• Verbose errors

  Stack traces and raw exception messages returned to clients reveal paths, versions, queries and internal hostnames.

• Files served by accident

  Serving the project root exposes .git, .env, backups and source maps, which can reconstruct the full source and its secrets.

• Secrets in git history

  A credential removed in a later commit is still in history and in every clone. If the repository is ever public, it is effectively published.

Sample: the risky pattern and the fix

const app = express();
app.use(express.static("."));            // serves .git, .env, source

app.get("/debug/env", (req, res) => res.json(process.env));

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

const app = express();
app.use(express.static("public", { dotfiles: "deny" }));

if (process.env.NODE_ENV !== "production") {
  app.get("/debug/health", (req, res) => res.json({ ok: true }));
}

app.use((err, req, res, next) => {
  const id = crypto.randomUUID();
  logger.error({ err, id }, "unhandled error");
  res.status(500).json({ error: "Internal error", id });
});

The original serves the whole project directory, exposes every environment variable on a public route and returns stack traces to clients. The fix serves only the public folder with dotfiles denied, keeps diagnostics out of production and returns a generic error with a correlation ID while logging the detail server-side.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Debug, admin and diagnostic routes, and whether they are gated to non-production
• Error handlers that return stack traces or exception messages
• Static-file serving roots and production source-map settings
• Secrets anywhere in the repository's git history (Gitleaks)
• Committed .env files, backups and config with internal hostnames

Scope and limits

• It doesn't do external reconnaissance: no OSINT, subdomain enumeration, port scanning or searching other sites. It reviews what your repository would expose.
• Gitleaks scans the history of the repositories you connect, not forks, mirrors or paste sites where a secret may have been copied.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.
• Infrastructure & IaC — Reviews Terraform, Helm, Ansible and server config for insecure defaults and exposure.