Astro PUBLIC_ variables and island hydration leaks
PUBLIC_ promises to ship. Islands can carry more than you typed if props pass secrets. Verify the deployed output free.
Astro ships mostly-static HTML with interactive islands. Two publication paths exist: PUBLIC_ env inlining, and props serialized into hydrated islands. Teams remember the first.
Both paths, plus the newer astro:env schema that helps when used.
The mechanism, precisely
Publication channels:
- import.meta.env.PUBLIC_* inlines at build across .astro and framework components alike.
- Island props serialize into the page for hydration — including objects a server helper attached.
- astro:env (typed schema) separates secret/public explicitly when adopted.
<Chat client:load secret={import.meta.env.SECRET_KEY} /><Chat client:load /> <!-- fetches /api/chat -->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
- getStaticPaths passing config blobs.
- Legacy import.meta.env.SECRET reads pre-schema.
Where the value belongs instead
The working pattern keeps the call on a context that holds secrets without serving them, and gives the browser an endpoint to ask instead.
Verify what your build actually ships
Search the deployed JavaScript for PUBLIC_ 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.
Why this keeps happening industry-wide
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 PUBLIC_. 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
astro:env solves this?
Typing helps declare intent; serialization through props remains a separate channel to watch.
Static-only sites?
Then PUBLIC_ is the whole story — audit it like any other published constant.
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.