Client Secrets: what to verify before client handoff

Handoff is where agencies discover that a Stripe secret, a cloud access key, or a bot token rode along in a production chunk. The mechanism is boring and therefore easy to miss: a build step inlined an env value into a public bundle, the CDN cached it, and every visitor can download it.

SlaySlop names the check Client-side secrets. Glossary definition: it "searches public bundles and responses for exposed keys and tokens." Before you send a portal link or a PDF, that is the observation I want closed on the routes you claim are done.

Outcome at handoff

Public pages and their downloaded assets should not expose secret-class keys or tokens. Publishable identifiers with intentional browser scope can remain, but anything that can bill, write data, or impersonate a service should be gone from client-reachable output.

The Security and secrets product flow matches the order I use in a lab notebook:

1. Inspect HTTPS and headers.
2. Search public assets for secrets.
3. Run vulnerability probes on the public surface.
4. Rank by exposure.

Step two is the handoff gate for this topic. Urgent leaks rise above cosmetic header work. Secrets stay redacted in findings so you do not leak the credential again through the report channel.

Boundaries to say out loud on the call

SlaySlop is a read-only public scan. It does not patch the site. It is not a pentest. You need ownership, management rights, or explicit permission. Acceptable Use forbids probing third-party sites without authorization.

A clean Client-side secrets row is not a claim about private git history, CI logs, or authenticated APIs. It is a claim about public bundles and responses the scan could fetch. Keep sibling checks in view:

• Exposed files and admin panels: publicly reachable env files, backups, and admin consoles
• Default credentials: unchanged vendor default logins when ownership is verified
• Known CVEs and TLS checks: different instruments on the same security pass

Happy path checklist before you send the portal

Walk the routes in the handoff scope. Marketing homepage, pricing, signup, and the app shell the client will click in the demo. Confirm the production build, not last week's staging preview.

Open the Client-side secrets findings if any exist. Read the asset path and pattern. Do not paste full secrets into the portal notes; the product gates sensitive values for that reason.

Reproduce the observation on a machine you control when you need a second opinion:

# Map a few public JS assets from a permissioned page
curl -sL "https://www.example.com/" | rg -o 'src="[^"]+\.js[^"]*"' | head

# Spot-check one chunk for high-signal prefixes (authorized hosts only)
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 at handoff. An immutable chunk with a leaked key stays available until the hash changes and the old object expires or is purged. Removing the line in source without a redeploy and cache bust leaves the old bundle live.

Confirm rotation happened at the provider when a true secret was exposed. Deleting a line without revoking the credential leaves the downloaded copy useful to anyone who already saved it.

Rescan the same URL after the fix. 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.

Pitfalls that still show up in week-one portals

Scanning only the brochure site while the client demo uses app. on another host. Public checks follow the URL you submit and what that crawl discovers.

Treating NEXT_PUBLIC_ or VITE_ prefixes as "safe because the framework said so." Those prefixes mean the value is for the client. They do not mean the value is non-secret.

Shipping source maps next to minified bundles. Maps can reconstruct original source and make an inlined secret easier to read. The secrets check still cares about the exposed value; maps just make the embarrassment faster.

Assuming a teaser scan from two sprints ago still describes Friday's release. Free teaser scans exist for public URLs; they are still a point in time. Handoff needs a fresh pass on the build you are actually delivering.

Related next step

If anything Client-side secrets-related is still open, delay the "we're done" email. Rotate, remove from client assets, purge or rehash CDN objects, rescan. Then share the portal.

Keep these open while you write the ticket: Client-side secrets, Security and secrets, Reports and portals. Soft product mention only when it helps: a permissioned SlaySlop scan is a faster way to attach redacted evidence to the handoff note than a screenshot of DevTools.