CRA and REACT_APP_: secrets baked into static files
Create React App inlines REACT_APP_* into HTML/JS at build. Legacy stacks leak too — scan any deployed URL free.
Create React App predates most of today’s stack anxiety, which is precisely why it still leaks: marketing sites and internal tools built in 2019 keep shipping with credentials nobody has audited since.
Same substitution, older grammar.
The mechanism, precisely
CRA inlines REACT_APP_-prefixed values into the bundle — and into index.html when referenced by %NAME%:
- Env read at build; %REACT_APP_X% replaced inside public/index.html directly.
- process.env.REACT_APP_X references substituted within bundled JS.
- Static hosting serves the result indefinitely — no rebuild, no expiry.
<title>%REACT_APP_MAPS_KEY%</title><title>AIzaFAKE000000000000000000000000000</title>Substitution is static and total: the literal replaces the reference everywhere the prefixed name appears, in every chunk, before anything is minified. Obfuscation changes what the string looks like; it does not change who can read it.
Variations of this mistake
- Service workers caching the inlined shell.
- Ejected configs drifting from upstream behavior.
Where the value belongs instead
Proxy provider calls through any existing backend or edge function; treat the CRA site as fully public surface (it is).
Verify what your build actually ships
Search the deployed JavaScript for REACT_APP_ in DevTools — thirty seconds, no tools beyond the browser. What you find is ground truth; everything earlier in the pipeline is intent.
Manual searching proves one page on one day. KeyDrift fetches the deployment the way a browser would, follows chunks named only in route manifests, reads streamed hydration payloads, and classifies what it finds — secret, or public-by-design — so an anon key never shows up dressed as an emergency.
Why snapshots are not enough
One more thing worth knowing before you close the tab: fixing this once does not end the story. Agents imitate whatever pattern is already in the repo, templates carry their own defaults, and the next feature request can reintroduce the same shape of code. Continuous monitoring re-scans every deploy and alerts only on change — new, regressed, resolved — so the comeback attempt is a notification instead of a quarter-end surprise.
The bigger picture
It helps to name the economics honestly. Fixing this class of leak costs minutes when caught at deploy time and days when caught at invoice time, because by then the credential has been harvested, validated, resold or drained — often all four. Detection latency is the entire game, which is why the monitoring half of KeyDrift exists alongside the scanning half.
How KeyDrift reports this exact finding
When KeyDrift finds this on your deployment, the report shows a masked value (first 8 and last 4 characters only), a salted fingerprint for tracking, the exact chunk filename carrying it, and a severity with written rationale. Public-by-design neighbours — anon keys, publishable keys, Firebase web constants — appear as informational context rather than noise, because knowing what should be there is what makes the real findings credible.
Manual check, step by step
A five-minute version you can run anywhere: view-source on the landing page, copy every src= script URL, fetch each and search the results for REACT_APP_. It misses manifest-only chunks and streamed payloads — which is precisely the gap between "I checked" and "it is clean" — but it catches the loud majority and builds the pattern-recognition that makes scanner output legible.
Close the loop with monitoring
Monitoring closes the loop that one-time verification leaves open. A scheduled scan refetches everything, diffs against history, and fires only on transitions: created, regressed, resolved. Regression alerts matter most here — they fire when a previously fixed finding returns, which in agent-era codebases is less a possibility than a schedule.
What the plans change
- Free $0 — 1 project · daily scans · email alerts · findings always visible.
- Indie $29/mo — 3 projects · hourly · Slack added · 80 chunks per scan.
- Team $89/mo — 15 projects · every 15 minutes · Discord + webhooks · 150 chunks.
- Growth — from $249/mo, quoted display-only until checkout ships.
The constant across every tier: plans limit how much is watched, never what a scan found. Visibility is structural, not promotional — asserted by tests over the entitlements model itself.
Common questions
Migrating off CRA anyway?
Then migrate config semantics too — prefixes differ across Vite/Next.
Old site, low traffic — still worth checking?
Attackers scan by pattern, not traffic. Exposure ages like milk.
Run a free scan at keydrift.dev/scan — paste a URL or the bundle source itself, no account. Findings arrive masked, with the exact chunk they live in.