Der Köder
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.
Wéi et funktionéiert
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.
Die Auswirkungen
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 checks
What FixVibe checks
FixVibe checks shipped client assets for high-confidence secret exposure signals and known credential formats. Reports identify the affected asset and rotation path. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Wasserdichte Verteidigung
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.
Die Quintessenz
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.