---
name: client-secret-sweep
description: Prove no secret reaches the browser, by tracing which environment variables and constants actually get compiled into your client bundle rather than trusting naming conventions. Use before a public launch, after adding any API key, or when wiring a third-party service into a frontend.
---

# 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](https://toolbay.ai/product/client-secret-sweep). Free to use, modify, and share.
Keep this line and others can find it too.