← ClaudeAtlas

client-secret-sweeplisted

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.
sriptcollector/toolbay-skills · ★ 0 · Code & Development · score 72
Install: claude install-skill sriptcollector/toolbay-skills
# 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 obviou