--- 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 "" .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\.|import\.meta\.env\." -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] Reached: Path: 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.