Skip to content
BuildThenTestedSee packages
MediumDeploy and config

Debug mode left on in production

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. How code reaches production and how the server is configured. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

# .env copied to the production host
NODE_ENV=development
DEBUG=*
// app/api/orders/route.ts
} catch (e) {
  return Response.json({ error: e.stack, env: process.env }, { status: 500 });
}
Development settings and verbose error output shipped to the live site, so every failure prints internals to whoever triggered it.

What happens

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.

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.

Check it yourself

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

  1. On the live site, open a page address that does not exist, then open an API route with a broken parameter, for example a letter where an id is expected.
  2. In browser devtools, open the Network tab, click the request and read the response body and headers.
  3. Look for stack traces, file paths, SQL text, the framework's development error overlay, or anything that looks like a key or connection string.
  4. Bad result: any of those appear in the response, or the page shows a red development error screen instead of a plain error page.

What we check

We probe every route with malformed input and inspect responses and headers for stack traces, framework debug pages, source maps and environment values. We also compare the deployed build against a production build of the same code.

Fix direction

Deploy the production build (next build followed by next start, or your host's production deploy) and set variables per environment in the host's settings instead of copying a local .env. Return a generic message to users and send the details to a log you control.

Mechanism documented in: How to optimize your Next.js application for production (verified 2026-09-21); Environment variables (verified 2026-09-21).

Covered by

Pre-launch check ($490, 48 hours) and Full audit ($1,900, 5 business days)

Both include a re-check after your fixes.

Compare packages

Related patterns

  • Secrets and internals in error messages and logsSecrets and keys

    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.

    High
  • Missing security headersDeploy and config

    Without these headers a browser will happily load the app inside someone else's page, over plain HTTP, or with injected scripts, which turns an otherwise small bug into a working attack.

    Medium
  • No automated checks before deployDeploy and config

    Type errors, broken imports and failing behaviour are discovered by users after deploy rather than by a machine before it, and each fix is another untested push.

    Medium
  • NEXT_PUBLIC_ prefix on a secretSecrets and keys

    The build writes the secret's value into public JavaScript, so anyone who loads the site can read it, and a redeploy with the same variable name republishes it.

    Critical

Questions

how do i know if my app is running in debug mode

Trigger an error on the live site, such as a missing page or an API call with a bad id, and read the response in devtools. A production build returns a short generic message; a development build often returns a stack trace, file paths or an error overlay. Also check the host's environment variables for NODE_ENV=development or DEBUG set on the Production environment.

is it bad to expose stack traces in production

A stack trace tells an outsider which files, libraries and queries your app uses and where it fails, which is a map for further probing. It can also include values from the request or the environment. Keep detailed errors in your logs and show users a plain message with a reference id.

next.js production build vs dev

Next.js's production checklist recommends running next build and then next start before going live; the dev server is for local work and shows detailed error overlays and unoptimised code. Hosts such as Vercel run the production build automatically and let you scope environment variables to Production, Preview and Development separately, so debug flags can stay out of production.

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