How SlaySlop checks Client Secrets

An attacker on the public surface does not need your staging VPN. They need a JS bundle, an HTML response, or a JSON payload that still carries a live key. SlaySlop's Client-side secrets check is built around that surface: it "searches public bundles and responses for exposed keys and tokens."

That one glossary line is the whole observation target. Everything below is how the security product frames the pass, what the finding can claim, and what it must not pretend to be.

Outcome the check is for

You want ranked findings when a secret-shaped value appears in public client assets or responses, with enough evidence to open the right file or route, and with sensitive values gated so you do not paste raw credentials into a ticket. The Security and secrets product page is explicit on both points: client bundles and responses are checked for exposed keys, tokens, and credentials; sensitive findings stay redacted so you do not accidentally publish full credential values.

Urgent leaks rise to the top. Lower-risk hardening stays below. That ranking matter more than a green badge on a marketing slide.

Boundaries I will not soften

Read-only. Public surface. Permission required. SlaySlop does not edit code, content, settings, or data on the target. Scanning a site you do not own, manage, or have permission to test violates Acceptable Use. The compare page is blunt: a pentest is authorized offensive testing; SlaySlop is a read-only scan of the public surface. It is not a pentest.

This check also is not a full secret inventory of your CI vault, your private repo history, or authenticated admin APIs. If the value never ships to a public bundle or response the crawl can see, Client-side secrets will not invent it.

Sibling security checks stay separate on purpose. Exposed files and admin panels looks for publicly reachable env files, backups, and admin consoles. Default credentials checks for unchanged vendor default logins on detected stacks when ownership is verified. Client-side secrets is the bundle-and-response slice.

Happy path: how the signal is observed

Published Security and secrets workflow:

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

Client-side secrets lives in step two. The product language is concrete: client bundles and responses are checked for exposed keys, tokens, and credentials. The Website scanner framing adds that checks run in parallel across security, SEO, performance, accessibility, secrets, and infrastructure after a real-browser crawl of public pages.

When I reproduce the idea locally on a host I am allowed to test, I look at the same class of artifact: built JS chunks, inline scripts, and JSON-ish responses that a visitor can download without a privileged session.

# Permissioned local sanity check against a public asset URL
# Replace with a URL you own or are authorized to assess
ASSET="https://staging.example.com/assets/index-abc123.js"
curl -sL "$ASSET" | rg -n "sk_live_|AKIA[0-9A-Z]{16}|xox[baprs]-|BEGIN (RSA )?PRIVATE KEY" || true

# Illustrative finding shape (values redacted in product UI)
check: client-side secrets
signal: exposed key/token pattern in public bundle
asset: /assets/index-abc123.js
evidence: matched provider-shaped token (redacted)
rank: urgent leak above header hardening

That local rg is not the SlaySlop check. It is how I confirm I understand the observation point before I argue with a report. The product keeps the real evidence next to the finding and redacts sensitive material.

What "public bundles and responses" actually means

Bundles are the JS (and related) assets the browser downloads for the page. Responses are the HTTP bodies the crawl can see on public routes: HTML with inline config, API-ish JSON that does not require a privileged cookie, source maps mistakenly left reachable, and similar visitor-visible payloads.

A secret that only exists in a server environment variable never referenced by client code is outside this check's public observation. A secret compiled into a Vite or Next client chunk because someone prefixed the wrong env var is exactly on the surface.

I care about what an attacker sees without logging in. That framing keeps the ticket honest.

Pitfalls when reading the result

No Client-side secrets finding is not a claim that your org has no leaked secrets. Private git history, CI logs, and chat paste dumps sit outside a public read-only scan.

A publishable browser key with hard referrer and quota limits is not the same risk class as a live secret key. The check searches for exposed keys and tokens; your remediation still has to classify which match is a true secret versus an intentionally public identifier. Do not treat every match as identical severity without reading the evidence.

Redaction is a feature, not a bug. If the UI gates the full value, do not demand the raw string in a shared agency portal. Rotate from the provider console using the pattern and asset path, not by screenshotting secrets into Slack.

Coverage follows what the crawl fetched. A deep link you never opened, or an asset behind auth, will not contribute findings. That matches the product boundary; it is not a promise that every chunk in every future deploy was scanned.

Related checks and next action

If Client-side secrets fires, treat it as an urgent leak until proven otherwise: rotate at the provider, remove the value from client-reachable assets, redeploy, then rescan the same URL. Pair the work with Exposed files and admin panels when .env or backup paths might also be public, and with Default credentials when a panel is reachable.

Catalog anchors: Client-side secrets, Security and secrets, and the checks index. Soft close only if useful: paste a URL you are allowed to test into SlaySlop and read the redacted evidence before you argue the key was "only in staging."