WHERE VIBE CODERS LEAK THEIR KEYS: 2026 FRONTEND SECRETS REPORT

We loaded 1,514 AI-built apps as a normal browser would and ran 100+ key signatures against everything the browser fetched. Six hundred and fourteen of them — 41% — shipped at least one secret key. This is the breakdown by key type, platform, and modal location.

Headline numbers

What is leaking, by key type

Stripe secret keys are the headline — 134 apps shipping a sk_live_ or sk_test_ to every visitor. The publishable / secret distinction is exactly where vibe-coding fails: builders paste both into the AI prompt because both are labeled “key”, and the AI does not consistently route the secret through a backend.

Where the keys are hiding

The 3% in source maps is the easiest fix and the most embarrassing — production builds with source maps publish your full source tree to the public. Most build tools default to producing source maps; few default to excluding them from production deployment.

Per-platform leak rate

Bolt.new’s higher rate reflects the platform’s preference for frontend-only quick-prototype patterns. Cursor’s lower rate is partly an artifact — Cursor users are more likely to be technical, more likely to introduce a backend, and therefore less likely to ship a secret to the browser at all. Lovable’s modal leak is service-role keys because builders paste them into the prompt as “the key” without realizing Lovable’s workflow expects only the anon key.

CWE / OWASP mapping by leak shape

The CWE varies with how the key reached the browser. The fix shape varies the same way.

The LLM-prompt path is the newest leak shape and the one most under-tested. We see it when builders paste sk_live_ into a Lovable prompt as “the Stripe key”, the model embeds it in a code path that reflects the prompt content into a debug error — and the error surfaces in production.

Per-leak-shape fix patterns

The mechanical fix per shape is short. Most teams stop at rotation and skip the proxy step — that is what produces re-leaks two weeks later.

# Step 1, every shape: rotate the key in the provider dashboard.
# Stripe: sk_live_ → revoke, generate new restricted key
# Supabase: project settings → reset service-role JWT
# OpenAI: platform.openai.com/api-keys → revoke + regenerate

// Step 2 for "inlined in JS bundle": move the secret to a server-only env,
// route the integration through a backend handler.

// WRONG — Vite inlines anything prefixed VITE_ into the bundle.
const stripe = new Stripe(import.meta.env.VITE_STRIPE_SECRET_KEY);

// RIGHT — secret stays server-only, frontend hits your route.
// app/api/charge/route.ts (Next) or supabase/functions/charge (Edge Function)
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
export async function POST(req: Request) {
  const session = await getSession(req);
  if (!session) return new Response(null, { status: 401 });
  // ... charge logic, returning only the public confirmation to the client.
}

// Step 2 for "returned by unauthenticated API call": auth-gate, then minimize.

// WRONG — public endpoint reflects the whole config object.
app.get('/api/config', (req, res) => res.json(serverConfig));

// RIGHT — return only what the client genuinely needs, post-auth.
app.get('/api/config', requireAuth, (req, res) => {
  res.json({ stripe_publishable_key: serverConfig.STRIPE_PUBLISHABLE_KEY });
});

// Step 2 for "source maps in production": ship maps off-platform.
// vite.config.ts
export default defineConfig({
  build: {
    sourcemap: 'hidden',  // generate but do not reference from production assets
  },
});
// Upload the maps to Sentry / Datadog at deploy time; never to the public bucket.

For LLM-prompt leaks, the fix is a hard rule: secrets never enter the prompt context. If the model needs to act on behalf of a user, mint a short-lived signed token scoped to the action and pass that — not the upstream API key.

The 24-hour cost of a Stripe sk_live_ leak

For the 134 apps leaking a Stripe secret key, we modeled the financial exposure assuming the key would be discovered within the industry-standard 5-15 minute window:

• Median apps’ Stripe daily volume. $440 (estimated from public payment-form metadata)
• Median refundable balance accessible. Last 30 days of charges, ~$13,200
• Median attacker-controllable refund window. 90 days from charge, full balance

A sk_live_ key in a frontend bundle gives an attacker the ability to refund every charge to a card they control. The financial damage of a single key leak ranges from “a Sunday’s revenue” to “the last quarter’s revenue”, depending on Stripe’s velocity flags.

Methodology

Sample. All 1,514 apps scanned between Nov 2025 and Apr 2026. The Token Leak Checker probe was applied to each.

Probe. Each app was loaded as a normal browser. Every fetched resource — initial HTML, JavaScript bundles, dynamic imports, source maps if served — was parsed and matched against 100+ regular expressions for known key formats, plus a high-entropy heuristic for likely-secret strings of unknown format.

Validation. Stripe and Supabase keys were validated structurally (format and checksum where present); we did not attempt any authenticated request against the provider, so the “leak rate” measures keys that look valid by format and were reachable, not keys we confirmed are active.

De-duplication. Multiple occurrences of the same key in the same bundle count once. Multiple distinct keys of the same type in the same app count separately.

Limits. This study measures keys present in the static or runtime-loaded bundle visible to a normal browser. It does not measure keys exposed only after authentication, keys exposed via debug endpoints triggered by query parameters, or keys exposed by side channels (server logs, error responses on edge cases).

Calibration against ref0. Every probe is also run against ref0 — a clean reference site that ships zero secrets. Any signature that fires on ref0 is a false positive and the rule is killed. The 100+ signatures in production are net of false-positive elimination; the per-key counts in the table above reflect only signatures that distinguished ref0 from a deliberately leaky scenario.

Reproduce on the public benchmark

Each leak shape maps to a live scenario on gapbench.vibe-eval.com. The scenarios are running; the curl commands return real, deliberate-by-design leaks today.

For the anatomy of how Supabase service-role keys end up in frontend bundles and how the fix looks per generator, see the companion pattern walkthrough: The Supabase service-role key in your frontend bundle and Source maps and .git in production.

How to reproduce a single data point

1. Open the Token Leak Checker.
2. Paste your live URL.
3. Read the report. Any key marked critical or high must be rotated immediately, then proxied behind a backend before re-deploy.

Citations

VibeEval. Where Vibe Coders Leak Their Keys: 2026 Frontend Secrets Report. May 2026. https://vibe-eval.com/data-studies/frontend-secrets-leak-report-2026/

Related

• Pattern walkthrough: The Supabase service-role key in your frontend bundle
• Pattern walkthrough: Source maps and .git in production — Next.js leaks you didn’t know you shipped
• Pattern walkthrough: Stripe trust on the wrong side — webhook signatures skipped, paid-flag tampering
• Data study: 2026 AI App Security Benchmark
• Data study: Supabase RLS in the Wild — 2026 Misconfiguration Atlas
• Data study: Honeypot Supabase: How Long Does a Public Anon Key Survive?
• Tool: Free Token Leak Checker