Client Secret Sweep

Client Secret Sweep

Install

Save this file as ~/.claude/skills/client-secret-sweep/SKILL.md, or .claude/skills/client-secret-sweep/SKILL.md to scope it to one repo. Claude Code auto-discovers it. Invoke with /client-secret-sweep or by asking "is any secret leaking into my frontend bundle?".

Why this exists

A secret in a client bundle is not a vulnerability you patch. It is a credential you must rotate, because it was served to every visitor and cached by every CDN and browser that touched it. Deleting the line does not un-publish it.

The naming conventions that are supposed to prevent this (NEXT_PUBLIC_, VITE_, REACT_APP_) only protect you when the value is read through the framework's own mechanism. They do nothing about:

• a server-only variable imported into a module that a client component also imports,
• a secret inlined into a config object that gets serialized to props,
• a key hardcoded as a string constant rather than read from the environment,
• a value that leaks through an error message or a debug payload.

So do not audit the names. Audit the built output.

Step 1: Inventory what counts as a secret here

ls -a | rg "^\.env"
rg -n "^[A-Z_]+=" .env.example 2>/dev/null

List every environment variable the project reads. For each, mark it PUBLIC (safe in a browser: a publishable key, a public URL, an analytics site ID) or SECRET (anything that authenticates, signs, or grants access).

If a variable's classification is not obvious, treat it as SECRET. Then check the provider's docs for that specific key. "Publishable" and "secret" are the vendor's words, and they are the authority, not the variable name.

Step 2: Find hardcoded credentials

Naming conventions cannot protect a literal:

rg -n "\b(sk|rk)_(live|test)_[A-Za-z0-9]{16,}|\bxoxb-[0-9]|\bgh[pousr]_[A-Za-z0-9]{20,}|\bAKIA[0-9A-Z]{16}\b|\bAIza[0-9A-Za-z_\-]{35}\b|-----BEGIN [A-Z ]*PRIVATE KEY" \
  --hidden -g '!node_modules' -g '!.git'
rg -n "(api[_-]?key|secret|token|password|passwd|credential)\s*[:=]\s*['\"][A-Za-z0-9_\-]{16,}" \
  -i --type-add 'code:*.{ts,tsx,js,jsx,py,rb,go,java,php}' -t code

Those patterns are deliberately anchored to each vendor's real key format. A loose sk_|rk_ looks thorough and is worse than useless: it matches inside ordinary identifiers like work_email, task_id, and risk_score, and a scan that cries wolf on every third file is a scan people stop running. If you widen these, widen them to a format a vendor actually issues.

Anything matching in a file that ships to the browser is a CRITICAL finding. Anything matching in a committed file at all is at minimum a rotation task, because git history keeps it.

Step 3: Build, then grep the actual output

This is the only step that proves anything. Everything before it is a hypothesis.

npm run build

Find the client output directory (.next/static, dist/assets, build/static, public/build) and search it for the literal VALUES of the secrets, not their names:

# for each SECRET var, take its real value from the local env file
rg -n --fixed-strings "<the actual secret value>" .next/static dist build 2>/dev/null

Never paste real secret values into a chat, a commit, or a report. Search for them, report only WHICH variable leaked and WHERE, and never echo the value itself.

Also search the bundle for the variable NAMES, which catches a secret embedded in a serialized config object:

rg -no "[A-Z][A-Z0-9_]{6,}" .next/static dist build 2>/dev/null | \
  rg -f <(rg -o "^[A-Z_]+" .env.example) 2>/dev/null | sort -u

Step 4: Trace the import boundary

For each secret that appeared, and for each that did not but is read in a module near client code, trace how it gets there:

rg -n "process\.env\.<VAR>|import\.meta\.env\.<VAR>" -t code

Then for each file that reads it, ask whether that file can reach a client bundle:

• Does it have "use client" at the top, or is it imported by a file that does?
• Is it imported by a shared module (lib/config, lib/env, constants) that client code also imports?
• Is it referenced in any component's props, state, or a serialized payload?

A single shared config module imported from both sides is the most common real cause. The server-only value rides along with the public ones.

Step 5: Check the leaky side channels

Secrets escape through more than bundles:

rg -n "console\.(log|error|warn)\(.*(process\.env|config|secret|token|key)" -t code
rg -n "JSON\.stringify\((process\.env|config)" -t code

Check also:

• Error responses that return the whole config or a stack trace to the client.
• Source maps shipped to production. A .map file next to your bundle can contain the original source, including inlined values.
• Client-side error reporting that captures full request objects, including authorization headers.

ls .next/static/**/*.map dist/**/*.map 2>/dev/null | head

Step 6: Report

[SEVERITY] <variable or credential name, never its value>
  Reached:  <bundle path where it appeared, or "not in bundle">
  Path:     <the import chain that carries it there>
  Action:   ROTATE / MOVE SERVER-SIDE / RECLASSIFY / NO ACTION

Severity:

• CRITICAL a SECRET value is present in built client output, or committed as a literal. This requires rotation, not just a code fix. Say that explicitly.
• HIGH a SECRET is read in a module that a client component imports, but did not appear in this build. It is one refactor away from shipping.
• MEDIUM source maps exposed, or secrets logged where logs are accessible.

Finish with the two counts you actually verified: how many secrets you searched the built output for, and how many appeared. If nothing leaked, say so plainly and name the build directory you searched, so the claim is checkable.

Rules

• Never print a secret value. Not in the report, not in a code block, not redacted-but-recognizable.
• Never claim the bundle is clean without building first. An unbuilt repo proves nothing.
• If a secret is already in git history, say that deleting the file does not remove it and that rotation is the only real fix.
• Do not rotate anything yourself. Report what needs rotating and let a human do it with the provider's console open.

From Toolbay. Free to use, modify, and share. Keep this line and others can find it too.