Env secrets check

Env and secrets check

Vibe-coded apps leak keys in a few predictable ways: a .env that was never ignored, a service key with a NEXT_PUBLIC_ prefix so it ships to every browser, or a key pasted straight into code. This skill finds those, ranks them, and walks the user through fixing and rotating. It reports names and short redacted hints only, never full values.

When to use

• Before the first git push, before making a repo public, before launch.
• After GitHub, a provider, or a stranger emails about a leaked key.
• "Is my .env safe?", "did I commit my Stripe key?", "should this be NEXT_PUBLIC?"

Steps

1. Run the scan from the project root.

   node scripts/secrets-scan.mjs . --json out/secrets-report.json --md out/secrets-report.md

   With git it scans tracked files plus new files git would add, and checks history for .env files. Without git it follows .gitignore.

2. Show the summary (High, Medium, Low counts) and every high finding in plain words: what leaked, where, and who can see it.

3. Sort the high findings into two piles:

   • Already exposed: the file is committed, in history, pushed, or deployed with a public prefix. These keys must be rotated. Moving them is not enough.
   • About to be exposed: not committed yet. Fixing the file is enough.

   Ask whether the repo has been pushed and whether it is public if you cannot tell. git log is fine for checking history.

4. Fix, with a yes for each change:

   • Add missing lines to .gitignore (.env*, !.env.example). Show the lines first.
   • For a committed env file, give the user the command git rm --cached <file> to run. It keeps their local copy.
   • For public-prefix secrets, rename the variable (drop the prefix), and move every use into server code (API routes, server actions, edge functions). Show the diff.
   • For hardcoded values, replace them with process.env.NAME and add NAME= to .env.example.
5. Rotation checklist. For each exposed key, write a numbered list in out/rotate-keys.md: the provider, where in its dashboard to roll the key, and where to paste the new one (local .env.local, then the host's env settings, then redeploy).
6. Re-run step 1 and show that high is 0.

Output format

# Secrets check: <project>
High 2 | Medium 3 | Low 1

## Rotate now (already exposed)
1. STRIPE_SECRET_KEY: committed in .env (git tracks it). Roll it in Stripe, Developers, API keys.

## Fix before you push
- .env.local is not in .gitignore. Added .env* (you said yes).

## Check
- NEXT_PUBLIC_MAPBOX_TOKEN ships to the browser. Fine if it is restricted by URL.

What is public on purpose

These are meant for the browser and are not findings: Supabase URL and anon (publishable) key, Stripe publishable key (pk_), Firebase web config, analytics IDs, Sentry DSN, Mapbox tokens restricted by URL. The anon key is only safe when RLS is on; suggest the supabase-rls-audit kit if the project uses Supabase.

Guardrails

• Never open, print, or paste the contents of .env files, and never repeat a full secret value. The script output is redacted; keep it that way.
• Never rewrite git history (filter-repo, force push) yourself. If the user wants history cleaned, explain the trade-offs and let them run it. Rotation matters more than history.
• Never call a provider API to test whether a key works.
• Never move a secret into a public prefix to "make it work" in the browser. The fix is a server route.
• A clean scan is not a guarantee. Say so, and mention keys in screenshots, logs, and chat messages too.

Env and secrets check

Finds secrets that are about to leak, or already have, before you push or launch. Then it helps you fix the files and gives you a checklist for rotating any key that was exposed.

For: anyone shipping an app built with Next.js, Vite, Expo, or similar, especially if a coding agent wrote the env setup for you.

Example

Input: a project with a .env.local that is not in .gitignore, NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY in it, and a password typed straight into lib/config.ts.

Output (out/secrets-report.md):

High: 2 | Medium: 3 | Low: 1

## High
- .env.local (env-file-not-ignored): This env file is not in .gitignore,
  so the next `git add .` commits it.
- .env.local:2 (public-env-secret): NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY is
  bundled into the browser. Anyone can read it in the page source.
  - Fix: Rename to SUPABASE_SERVICE_ROLE_KEY, read it only in server code.

## Medium
- lib/config.ts:2 (hardcoded-secret, let... (12 chars)): adminPassword is
  set to a hardcoded value in code.

Values are always redacted. Try it on the bundled demo: node scripts/secrets-scan.mjs examples/demo-app.

What it checks

• .env files tracked by git, not ignored, or found in git history.
• Server secrets behind NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_, REACT_APP_, NUXT_PUBLIC_, GATSBY_, PUBLIC_.
• Stripe, AWS, GitHub, OpenAI, Anthropic, Slack and Google key shapes, private keys, database URLs with passwords, Supabase service_role keys.
• Secret-named variables with hardcoded values, and templates (.env.example) holding real-looking values.

What it can access

• Reads files in your project (skipping node_modules, build output, and lockfiles). It reads .env files only to check names and whether values are set.
• Runs its own script, plus git ls-files and git log to see what is committed.
• Writes reports to out/, and edits .gitignore only after you say yes.
• No network, no env vars.

Setup

None. Needs Node 22 or later. Git is optional.