What it is
Walking through production JavaScript bundles for leaked credentials is the most reliably-rewarding security activity I know. Stripe live keys, AWS access keys, GitHub personal access tokens, Sentry DSNs with project-write scope, internal API base URLs, hard-coded admin emails â all routinely shipped to every visitor. The mistake is almost always architectural: a developer wrote `process.env.SECRET_KEY` in code that gets bundled for the client, the framework helpfully inlined it, and now it's on the CDN.
How it happens
Modern bundlers (Webpack, Vite, esbuild, Next.js) replace `process.env.X` references at build time. If the build environment has the variable set, the value is inlined into the output JS. Frameworks differentiate public from private vars by prefix (Next.js: `NEXT_PUBLIC_`; Vite: `VITE_`; Create React App: `REACT_APP_`) â but the prefix is a *convention*, not a sandbox. A direct `process.env.SUPABASE_SERVICE_ROLE_KEY` in a component file gets inlined just the same.
What an attacker gets
Severity tracks the leaked secret. A Stripe live secret is account-takeover for your billing. An AWS access key is your cloud bill, your S3 buckets, and potentially RCE via Lambda. A Supabase service role key bypasses RLS entirely. A GitHub PAT with `repo` scope is your source code and CI secrets. Discovery time for an attacker is seconds â there are public scrapers and search-index queries continuously looking.
// what fixvibe reports
What FixVibe reports
Runs on every URL scan: paste your app's URL, nothing to install. The free preview shows your top findings; Hobby and above unlock the full report. Each finding shows the affected URL or host, its severity and fix steps you can paste into your AI coding tool.
How to fix it
Treat the client bundle as a publication channel: never put a private secret in code that ships there. Use server-side endpoints for any operation that needs a private key â the client calls your API, your API holds the key. Use the framework's prefix convention rigidly: `NEXT_PUBLIC_*` for client, everything else stays server-only. In Next.js, mark server-only files with `import 'server-only'` so a stray client import becomes a build error. Add CI checks that scan built artifacts for known secret patterns before deploy (gitleaks, trufflehog, our scanner). Rotate any secret that has ever shipped client-side as if it were leaked â because it was.
Key takeaway
The fix isn't a tool â it's the mental model. There are public secrets and there are private secrets, and the rules are not the same.