Secrets and internals in error messages and logs

Keys, session tokens and database connection strings end up in log files and in HTTP responses that anyone can trigger, which hands out credentials and a map of the system's internals. API keys and passwords the app uses to talk to other services. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

// app/api/checkout/route.ts
} catch (err) {
  console.log('checkout failed', { err, headers: req.headers, env: process.env })
  return Response.json({ error: String(err), stack: err.stack }, { status: 500 })
}

An error handler that prints the whole environment and request headers to the log, and returns the stack trace to the caller.

What happens

Keys, session tokens and database connection strings end up in log files and in HTTP responses that anyone can trigger, which hands out credentials and a map of the system's internals.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Seen in public

CodeRabbit reviewed 470 open-source GitHub pull requests (320 AI co-authored, 150 human-only) and found AI co-authored pull requests contained about 1.7 times more issues overall and up to 2.74 times more security issues.

470 Pull requests analysed
320 AI co-authored PRs
150 Human-only PRs
about 1.7x Issues overall vs human-only
up to 2.74x Security issues vs human-only

Dec 2025 · CodeRabbit · all sources

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

Open your live app, right-click, choose Inspect, then the Network tab. Trigger an error on purpose: submit a form with a field left blank, or visit an address like /api/anything-made-up.
Click the failed request and read the Response tab. Look for file paths, stack traces, SQL text, connection strings or anything that looks like a key or token.
In your hosting dashboard (Vercel: Logs; Supabase: Logs; Firebase: Functions logs), search for Bearer, password, sk_live, apikey and Authorization.
A bad result is a response body with internal detail, or a log line that includes a credential or a full request header set.

What we check

We send malformed and unexpected requests to every endpoint and inspect the responses for leaked internals, then review the log configuration and sample log lines you share with us for credentials and tokens. The report shows each leaking endpoint and the exact data returned.

Fix direction

Return a generic error message to the caller and keep the detail in server-side logs, as OWASP's error handling guidance describes. In the log call itself, mask or drop passwords, tokens, keys and full headers, and never log the whole environment object.

Mechanism documented in: Logging Cheat Sheet (verified 2026-09-21); Error Handling Cheat Sheet (verified 2026-09-21).

Covered by

Pre-launch check ($490, 48 hours) and Security sweep ($290, 24 hours)

Both include a re-check after your fixes.

Compare packages

Related patterns

Debug mode left on in productionDeploy and config
Anyone who causes an error sees file paths, query text and sometimes environment values, and dev-only shortcuts such as skipped checks or seeded test users stay active for real visitors.
Medium
Third-party API key in the JavaScript bundleSecrets and keys
Anyone who views the page source can take the key and run up charges, send messages or pull data on your account until the key is revoked.
High
Errors swallowed, spinner never stopsReliability
When a request fails, users see a spinner that never ends or an empty list, assume the app is broken or their data is gone, and nobody on your side hears about it.
Medium
Secrets committed to the code repositorySecrets and keys
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
Critical

Questions

is it bad to show stack traces to users

Yes. A stack trace reveals file paths, library versions and sometimes query text or configuration values, which gives an attacker a map for the next step. OWASP's guidance is to return a short generic message to the user and record the full detail in server-side logs only.

what should never be logged

Passwords, session identifiers, access tokens, API keys, encryption keys and full authorization headers. OWASP's logging cheat sheet lists these as data to exclude or mask. Logging the whole request or the whole environment object is the usual way they slip in, so log named fields instead.

how do i check if my app leaks secrets in error messages

Trigger a few errors on purpose in your live app: a blank form, a made-up API address, a request with the wrong content type. Read each response in the Network tab of the browser's developer tools. Then search your hosting provider's logs for Bearer, password and key prefixes. Anything you find should be masked and, if it is a live key, rotated.

Back to the catalogue, or run the self-check for your stack.