Checklist: client secrets on public pages

Uptime can be green while a billing key sits in a hashed chunk. That is the embarrassment that shows up on a handoff call when nobody opened the secrets row. SlaySlop names the check Client-side secrets. The glossary says it "searches public bundles and responses for exposed keys and tokens." This checklist is the process that survives launch week, not a slide that says "security done."

Outcome this list is aiming for

Public pages in the handoff scope should not expose secret-class keys or tokens in HTML, JS, or related responses. Publishable identifiers with intentional browser scope can remain. Anything that can bill, write data, or impersonate a service should be gone from client-reachable output before you send the portal link.

Boundaries to say once at the start of the call

SlaySlop is a read-only scan of the public surface. You need ownership, management rights, or explicit permission. The compare page is blunt: it is not a pentest. A clean Client-side secrets result is not vault hygiene, not a private-repo audit, and not a signed offensive engagement.

Sibling checks cover different holes. Exposed files and admin panels catch reachable env and backup files. Default credentials covers unchanged vendor logins when ownership is verified. Keep them on the board without merging the stories.

Checklist I actually bring

Walk these in order. Skip steps and you will invent confidence on the call.

1. Confirm the URL is the one the client will click. Marketing homepage, pricing, signup, checkout shell, and the app. host if that is the demo path. Staging clearances do not clear production. Public checks follow the URL you submit and what that crawl discovers.

2. Run the security pass, not a screenshot of the padlock. Security and secrets describes the order: inspect HTTPS and headers, search public assets for secrets, run vulnerability probes, rank by exposure. Step two is the gate for this topic. Urgent leaks rise above cosmetic header work.

3. Open Client-side secrets findings if any exist. Read the asset path and pattern class. Do not paste full secrets into Slack, email, or the shared portal. Product copy is explicit: secrets stay redacted so you do not leak the credential again through the report channel.

4. Reproduce fetchability on a machine you control when you need a second opinion.

# Permissioned hosts only: map public JS, then spot-check prefixes
curl -sL "https://www.example.com/" | rg -o 'src="[^"]+\.js[^"]*"' | head
curl -sL "https://www.example.com/assets/main.js" \
  | rg -n "sk_live_|sk_test_|AKIA|xoxb-|ghp_|AIza" || echo "no prefix hits in this chunk"

GET /assets/main.js HTTP/2
host: www.example.com
accept: */*

HTTP/2 200
content-type: application/javascript
cache-control: public, max-age=31536000, immutable

Cache headers matter. An immutable chunk with a leaked key stays available until the hash changes and the old object expires or is purged. Removing a line in source without a redeploy and cache bust leaves the old bundle live.

5. Classify before you panic. Publishable Stripe keys, maps keys restricted by HTTP referrer, and similar browser identifiers are meant to appear in client code when scoped correctly. Secret-class credentials are not. Collapsing every match into the same severity creates noise that clients stop trusting.

6. Rotate at the provider first when the value is secret-class. Deleting a line without revoking the credential leaves every downloaded copy useful to anyone who already saved it. Then remove the value from client-reachable output, redeploy, purge or rehash CDN objects.

7. Rescan the same production URL. Fix prompts and integrations product copy describes the loop: open the finding, copy a fix prompt if you use an agent workflow, then scan again to confirm the issue is gone. Launch week needs that second pass, not last Tuesday's teaser scan.

8. Attach a scoped note to the portal. Say what was checked, when, and whether Client-side secrets fired. Link the glossary definition. Do not invent prices or check counts beyond what pricing and the checks catalog already publish (forty-five checks across seven categories).

Pitfalls that still embarrass agencies

Scanning only the brochure site while the demo uses another host. Treating NEXT_PUBLIC_ or VITE_ as "safe because the framework said so." Those prefixes mean the value is for the client, not that it is non-secret. Shipping source maps next to minified bundles so an inlined value is easier to recover. Equating TLS padlocks or Lighthouse slides with a secrets inventory. Saying "staging only" about a public staging URL that contractors and Slack previews already fetch.

Grepping the repo and skipping the shipped response is another classic. Source without a prefix can still produce a bundle that contains one after a plugin injects config. Observing public bundles and responses is the point of the check.

Related next step

If anything Client-side secrets-related is still open, delay the "we're done" email. Rotate, remove, purge, rescan. Then share the portal. Keep Reports and portals and Security and secrets handy so the handoff note matches the product wording.

Soft product mention when it helps the process: a permissioned SlaySlop scan attaches redacted evidence faster than a DevTools screenshot in a PDF nobody re-reads after launch week.