Secrets in Client Bundle Check — Is Your Key Shipped to Every Browser?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
A secret referenced with a public/browser-visible prefix (NEXT_PUBLIC_*, VITE_*, CRA REACT_APP_*) is bundled into your client JavaScript and shipped to every visitor. Browser-visible means anyone can read it.
Why AI tools generate it
AI tools default to public env prefixes so the client can call the API directly, and they often move a key there 'just to make it work' without flagging that it's now public.
How DevMeth detects it
A code scan looks for secret-shaped values wired through client-visible env prefixes or otherwise bundled into the shipped client, and flags the location.
Secrets are baked into your client bundle — every visitor's browser receives them
WHAT WE FOUND
.env.local — public prefix — NEXT_PUBLIC_SUPABASE_SERVICE_ROLE=…c3d4 (masked)
The fix, in three steps
Move the key into a server-only environment variable and proxy calls through an API route instead of the browser. Our fix prompt does this in three steps with a verification line.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
What's wrong with NEXT_PUBLIC_ for a secret?
Anything under a public prefix is included in the code shipped to the browser, so every visitor (and attacker) can read it. Only non-secret public values belong there.
Is the client bundle scan repo-only?
The repo half checks for public-prefixed secrets in source; a paired live check also inspects the JavaScript your deployed site actually serves.
How do I fix it?
Rotate the key, move it to a server-only env variable, and call your API through a server route that injects it server-side.
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.