API Key Exposure
API key exposure occurs when secret credentials intended for server-side use are accidentally included in client-side code, version control, or public assets where unauthorized parties can access them.
Understanding API Key Exposure
API keys and secrets authenticate your application to third-party services and grant access to their resources. When these credentials are exposed in frontend JavaScript bundles, public repositories, or build artifacts, anyone can extract them and make requests on your behalf, potentially incurring costs, accessing private data, or performing destructive operations.
The most common exposure vectors are hardcoding secrets in frontend code, committing .env files to Git, including secrets in client-side environment variables (e.g., NEXT_PUBLIC_ or VITE_ prefixed variables), and logging secrets in error messages or analytics. Even if a secret is later removed from code, it remains in the Git history unless the history is rewritten.
It is critical to distinguish between public and secret keys. Some keys are designed to be public: Firebase API keys, Supabase anon keys, and Stripe publishable keys are meant to be in frontend code. Their security model relies on server-side rules, not key secrecy. However, keys like Stripe secret keys, database passwords, service role keys, and third-party API keys with write access must never appear in client-side code.
Prevention requires a combination of environment variable management, .gitignore configuration, secret scanning in CI/CD pipelines, and runtime checks that verify secrets are not included in client bundles. Services like GitHub also offer push protection that blocks commits containing detected secrets.
Why This Matters for Vibe-Coded Apps
AI code generators frequently hardcode API keys directly in source files to make the code work immediately. When you paste an API key into a prompt or the AI sees one in your codebase, it may spread that key across multiple files. Vibe coders who rapidly iterate with AI tools often skip the step of moving secrets to environment variables, leaving them embedded in committed code.
A critical pattern in vibe-coded apps is confusing public and secret keys. AI-generated Supabase code might use the service_role key in frontend code instead of the anon key, exposing full database access. Always verify which key the AI chose and whether it belongs on the client or server side.
Real-World Examples
Uber GitHub Secret Exposure (2016)
Uber developers committed AWS credentials to a private GitHub repository. Attackers who gained access to the repo extracted the keys and used them to access an S3 bucket containing personal data of 57 million riders and drivers.
Travis CI Secret Exposure (2021)
A flaw in Travis CI exposed environment variables including API keys and tokens from thousands of open source projects through the API. Secrets that developers assumed were private were accessible to anyone who queried the right endpoints.
Samsung Source Code Leak (2022)
The Lapsus$ group extracted 190GB of Samsung source code from a repository that contained embedded API keys and secret credentials, including keys for Samsung's SmartThings platform and backend services.
Frequently Asked Questions
Are Firebase API keys safe to expose in frontend code?
Yes, Firebase API keys are designed to be public. They identify your Firebase project but do not grant access to data on their own. Security is enforced by Firebase Security Rules on Firestore, Realtime Database, and Storage. The same applies to Supabase anon keys and Stripe publishable keys. However, Firebase service account keys, Supabase service_role keys, and Stripe secret keys must never be exposed.
How can I check if secrets are in my Git history?
Use tools like git-secrets, truffleHog, or GitLeaks to scan your entire repository history for patterns matching API keys, passwords, and tokens. GitHub also provides secret scanning alerts for public repositories and push protection for private ones. If you find an exposed secret, rotate the key immediately — removing it from the code is not sufficient because the Git history retains the old value.
What is the difference between NEXT_PUBLIC_ and regular env vars in Next.js?
Environment variables prefixed with NEXT_PUBLIC_ are bundled into the client-side JavaScript and sent to every user's browser. Regular environment variables are only available on the server side. Never put secret keys in NEXT_PUBLIC_ variables. The same pattern applies to VITE_ in Vite and REACT_APP_ in Create React App — these prefixes mark variables for client-side inclusion.
What should I do if I accidentally exposed an API key?
Rotate the key immediately — do not just remove it from the code. The old key is still in Git history and may have been cached by search engines, CDNs, or web archives. After rotating, audit your logs for unauthorized usage during the exposure window. Then add the secret to .gitignore, move it to environment variables, and set up a pre-commit hook or CI secret scanner to prevent future leaks.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to api key exposure and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan