Your VITE_ API key is public. Here's what happens next, and three ways to fix it

KeyVault Edge — Fri, 23 Oct 2026 12:32:43 +0000

If your frontend reads an AI or payments key from import.meta.env.VITE_SOMETHING, that key is in the JavaScript bundle every visitor downloads. Same for NEXT_PUBLIC_* in Next.js and REACT_APP_* in Create React App. Putting it in a .env file changes where it's stored on your laptop, not where it ends up.

You can check in ten seconds: open your deployed site, open DevTools → Sources, and search the bundle for your key's prefix (sk-, AIza, sk_live_).

What happens after a key ships in a bundle

Automated scanners crawl deployed sites and public repos for those prefixes. Developers have described the results publicly this year on Google's own forum, for example about $6,000 in roughly 40 minutes from an AI Studio sample exported to Vite, and about $2,200 from a VITE_GEMINI_API_KEY used as a shared fallback.

Providers have added protections (Google now rejects unrestricted Gemini keys and offers project spend caps; OpenAI has project limits), but those work per project or account, not per key, and they don't stop the key from being copied.

If it already leaked: the first hour

Revoke or regenerate the key in the provider console. Don't wait to check whether it was used.
Check usage for the window since the deploy: unfamiliar models, regions or volume.
Restrict every remaining key to only the APIs it needs, and set a budget alert.
Remove the key from the bundle (below) before you deploy again.
If it was ever committed, it's also in git history. Rewrite history or make the repo private, and turn on GitHub push protection.

Three ways to keep the key out of the bundle

1. A small backend endpoint. A serverless or edge function holds the key as a secret; your frontend calls the function. Free, and the right answer if you'll also add rate limiting and per-user budgets.

2. The provider's own client-side option, if it has one. For example, Firebase App Check with Firebase AI Logic for Gemini on mobile and web.

3. An edge proxy with per-key limits. You store the real key once and your app sends a stand-in token instead. The proxy adds the real key and forwards the call, and each token carries its own rate limit, allowed endpoints, spend cap and an off switch. I build one of these, KeyVault Edge. You can watch it allow one request and block two misuse attempts on a live demo, no signup.

One honest limit for option 3 (and for any token a browser can see): the token can still be copied and replayed from a server. The point is that a leaked token has hard limits and can be revoked in one click without rotating the provider key, so the damage is bounded.

A quick checklist

[ ] No provider key in any VITE_, NEXT_PUBLIC_ or REACT_APP_ variable
[ ] Bundle searched for key prefixes after every deploy
[ ] Each key restricted to the APIs it needs
[ ] Budget alert and spend limit set at the provider
[ ] Push protection on for the repo

How did your key end up in the frontend? I'd like to hear what made it the easiest option at the time.

How to audit your codebase for exposed API keys (free tools)

KeyVault Edge — Mon, 05 Oct 2026 11:13:20 +0000

Accidental credential commits are often found weeks or months after they happen, long after anyone who was watching had time to use them. This guide walks through a systematic audit of your repositories, git history, Docker images and CI pipelines using free, open-source tools.

What you're scanning and why

A credential audit is not just scanning your current working tree. Secrets committed to git are permanent in history unless you rewrite it. Deleting a file does not remove the secret: the commit with the original file is still reachable via git log and git show.

A proper audit covers:

Full git history: every commit, including deleted files and reverted changes
All branches and tags: feature branches often hold secrets that never reached main
Docker image layers: build-time ARG and ENV instructions that baked secrets in
CI/CD configs: .github/workflows, .gitlab-ci.yml, and environment variables echoed into logs
Lock files: rarely, npm/yarn lockfiles contain registry auth tokens
Build artifacts: compiled frontends that embedded env vars at build time

Scanning git history with Gitleaks

Gitleaks (MIT) is one of the most widely used open-source secret scanners, with built-in rules for OpenAI, AWS, Stripe, GitHub, Twilio and most major providers.

# Install (macOS)
brew install gitleaks

# Install (Linux)
curl -sSL https://github.com/gitleaks/gitleaks/releases/latest/download/gitleaks_linux_x64.tar.gz | tar -xz
sudo mv gitleaks /usr/local/bin/

# Scan full git history of the current repo
gitleaks detect --source . --verbose

# Write a JSON report
gitleaks detect --source . --report-path gitleaks-report.json --report-format json

detect scans every commit. On large repos it can take a few minutes; --log-opts accepts any git log options, e.g. --log-opts="--since=2025-01-01" to scan recent history only.

Add it as a pre-commit hook so new secrets never land:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.0
    hooks:
      - id: gitleaks

pre-commit install

Deep scanning with TruffleHog

TruffleHog (AGPL-3.0) goes further by verifying detected credentials against their upstream APIs: it tells you not just that a string looks like an OpenAI key, but whether that key is currently valid.

# Scan local git history, verified findings only
trufflehog git file://. --only-verified

# Scan a public GitHub repo
trufflehog github --repo https://github.com/yourusername/yourrepo

# Scan every repo in an org
trufflehog github --org yourorgname --only-verified

--only-verified is great for triage: it filters out false positives and surfaces credentials that are exploitable right now.

Scanning Docker images

Images built with ARG or ENV instructions that reference real keys bake those keys into a layer permanently. A later instruction that overwrites the variable doesn't help: the earlier layer is still in the image.

# Scan a local or registry image
trufflehog docker --image yourimage:latest

# Quick manual check of every layer
docker save yourimage:latest | tar -xO | strings | grep -E 'sk-proj|AKIA|ghp_'

The classic mistake:

# Bakes the real key into an image layer: don't
ARG OPENAI_API_KEY
ENV OPENAI_API_KEY=$OPENAI_API_KEY
# Inject at runtime instead (docker run -e, or your orchestrator's secrets)

Auditing CI/CD pipelines

Build logs are often public, especially in open source. Look for:

env: blocks with literal values (OPENAI_KEY: sk-proj-...). References like ${{ secrets.X }} are fine.
Steps that print the environment: run: echo $OPENAI_API_KEY, env, printenv.
Test scripts that hardcode keys "for easier local testing".
Cached artifacts that include environment dumps from crash reporters.

GitHub's built-in scanning

GitHub secret scanning runs on public repositories and can be enabled for private ones on paid plans. For partner patterns (OpenAI, Stripe, AWS and many more) GitHub also notifies the provider, which may revoke the key.

Turn on push protection under Settings → Code security → Secret scanning to block commits containing known secret patterns before they land.

When you find something

Rotate the credential immediately. Don't wait for the history rewrite; assume it's compromised.
Check for unauthorised usage in the provider's logs (OpenAI usage page, AWS CloudTrail, Stripe logs).
Remove it from history with git filter-repo (not filter-branch), force-push everywhere, and have contributors re-clone.
Ask GitHub support to clear cached views of the old commits; rewriting history doesn't purge them.
Assume forks still have it. You can't rewrite other people's forks, which is why step 1 comes first.

Making the next leak cheaper

Scanning finds the leaks you can see. The other half is making a leaked string less valuable: scoped keys, spending limits, and short-lived or origin-bound tokens.

That second half is what I'm building with KeyVault Edge: your code ships a token that the edge proxy only exchanges for the real key on requests from origins you allow. It's one layer, not a replacement for rotation and scanning.

Originally published at keyvaultedge.com.

DEV Community: KeyVault Edge