Case Studies

5 real exposed API key disasters (and how to avoid being next)

VibeSafe · June 29, 2026 · 6 min read

Exposed API keys are the single most common security mistake in AI-generated code, and the consequences are rarely theoretical. These are five patterns of real incidents the security community has documented widely — the names and exact amounts vary by report, but the mechanism is identical every time, and it's worth understanding precisely because it's so preventable.

1The committed Stripe key

A founder pushes a working payment integration to a public GitHub repo, with the live Stripe secret key sitting directly in the source file. Within hours — sometimes minutes — automated bots that continuously scan GitHub for key patterns find it. The key gets used to attempt fraudulent charges or query customer payment data before the founder even notices the commit.

The fix: Stripe keys belong in environment variables, never in a file that gets committed. If a key has ever touched a public repo, rotate it immediately — assume it's compromised even if you don't see suspicious activity yet.

2The five-figure AWS bill

An AWS access key, hardcoded for convenience while testing an S3 upload feature, ends up in a public repository. Crypto-mining bots — which specifically hunt for AWS credentials — pick it up and spin up dozens of high-powered compute instances under the account owner's billing. The first sign of trouble is often the invoice, not an error message.

The fix: Use IAM roles with the narrowest possible permissions, never the root account's keys, and set AWS Budget alerts so an unexpected spend triggers a notification within hours, not at the end of the billing cycle.

3The drained OpenAI quota

A side project ships with an OpenAI API key embedded directly in client-side JavaScript — visible to anyone who opens browser dev tools, no GitHub leak required. Within a day, the key is being used by unrelated traffic, and the monthly quota that was supposed to last a month is gone in hours.

The fix: Never call a paid AI API directly from the browser. Route it through your own backend endpoint, where the key stays server-side and you can add rate limiting per user.

4The open Supabase table

A Supabase project ships with the public anon key in the frontend — which is normal and expected — but without Row-Level Security enabled on the tables. Anyone with that public key, which is visible in the browser by design, can query every row in every table directly, because there's no database-level rule restricting access.

The fix: The anon key is meant to be public. What's not optional is enabling RLS and writing policies that scope every query to the requesting user. Without that, the public key is effectively a master key.

5The forgotten staging key

A key gets hardcoded "just for testing" in a staging branch, with every intention of removing it before the merge to production. The branch gets merged anyway, months later, by someone who didn't write that line and has no idea it's there. The key sits live in production code, undiscovered, until a routine audit — or an attacker — finds it.

The fix: Treat "temporary" hardcoded secrets as a thing that doesn't exist. If a key needs to go in code even briefly, it needs an environment variable from the first line, not a TODO to fix it later.

The common thread

None of these required a sophisticated attacker. Every single one was found by automated scanning — the same kind of scanning a security tool can run on your own code before you ship, instead of after someone else finds it for you.

Scan for exposed keys free →

3 free scans every month · Your code is never stored