Secret published through a browser-exposed environment variable
`{name}` is compiled into JavaScript that every visitor downloads, so its value is public.
Why it matters
`{name}` is compiled into JavaScript that every visitor downloads, so its value is public. The `{prefix}` prefix instructs the build tool to inline the variable into the client bundle — it is meant for values that are safe to publish, never for a secret. Anyone can read this key from the page source and use it directly against the service it belongs to. Rotate it and move it to a server-only variable; removing the prefix alone does not undo the exposure.
How ShipReady detects it
AI-specific exposure — the product's differentiating module. Covers two distinct failure modes of AI-built applications: 1. Tooling artifacts deployed by accident. AI coding tools generate config and instruction files at the repo root; developers who push a whole repo (rather than just its build output) to static hosting serve them publicly. Some are merely instructions; others hold live API keys. 2. Secrets promoted into the client bundle via a PUBLIC env var prefix. This is the single most characteristic AI-app mistake: AI assistants correctly explain that a variable must be prefixed (NEXT_PUBLIC_, VITE_, ...) to be readable in the browser, and developers apply that prefix to a *server* secret. The bundler then inlines the real value into JavaScript that anyone can read. Both are confirmed by observation, never inferred from framework fingerprints alone.
Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.3.0.
How to fix it
This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.
The environment variable {variable} carries a browser-exposed prefix (NEXT_PUBLIC_/VITE_/REACT_APP_/etc.), so your build tool inlines its value into client JavaScript that anyone can read. Do two things, in this order: (1) rotate the credential — it is already public and removing the prefix will not un-publish the copies already shipped; (2) move it to a server-only variable with no public prefix, and read it only in server code (a server component, route handler, or server action). If the browser genuinely needs this capability, put it behind a server endpoint you control instead of shipping the key.Frequently asked questions
- What does "Secret published through a browser-exposed environment variable" mean?
- `{name}` is compiled into JavaScript that every visitor downloads, so its value is public.
- How serious is it?
- ShipReady rates this critical. Fix before launch. On its own, this is enough to compromise the application.
- How do I fix it?
- Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.
- Can I check my own site?
- Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check.
Related checks
Does your site have this?
ShipReady checks this and 73 other things across up to ten pages of your site. Free, no signup.
Scan my site