Your VITE_ keys are public: secrets in the browser bundle
Anything prefixed VITE_, NEXT_PUBLIC_ or REACT_APP_ ships to every visitor. AI builders routinely put service-role keys and provider secrets there. Here is how to tell what you leaked.
Modern bundlers only expose environment variables with a specific prefix to client code — VITE_ for Vite, NEXT_PUBLIC_ for Next.js, REACT_APP_ for Create React App. That prefix is a promise: "this value is public." Everything with it is compiled into the JavaScript every visitor downloads.
AI builders do not reliably understand that distinction. We regularly see Stripe secret keys, Supabase service-role keys, OpenAI keys and SMTP passwords prefixed VITE_ and shipped to the browser — because the model needed the value available in a component and reached for the prefix that "worked."
What counts as a leaked secret
Service-role / admin keys (Supabase service_role, Firebase admin) — full bypass of all access rules. Provider secrets that bill you: Stripe sk_live_, OpenAI/Anthropic keys, Twilio, SendGrid. SMTP credentials, database connection strings, signing secrets for JWTs.
How to check
Open your deployed site, view source on the largest JS chunk, and search for the obvious prefixes: sk_, service_role, AKIA, -----BEGIN. Better: let a scanner walk every loaded script for you. VibeSafely downloads each bundle and pattern-matches known secret shapes, then tells you which file and roughly where.
The fix
Move every real secret to server-side code (an API route, edge function or backend) — never a VITE_/NEXT_PUBLIC_ variable. Rotate any key that ever shipped to the browser. Assume it is compromised; it was public. Keep only genuinely public values (publishable keys, anon keys with RLS) on the client.
See what your app left exposed.
One free scan, sixty seconds, no credit card — every finding with a copy-paste fix.
Scan my site — free