Common Client Secrets mistakes that still ship

Thin meta tags are easy to spot in a crawler report. A live API secret inside a hashed JS file is easier to miss and worse when it ships. Both problems live on the public web, but only one tends to show up in an SEO checklist. Client-side secrets belong on the launch list anyway.

SlaySlop's glossary entry is short on purpose. Client-side secrets "searches public bundles and responses for exposed keys and tokens." The mistakes below are the patterns that still put those values where crawlers, users, and anyone with curl can read them.

Outcome if you stop shipping these

Public HTML, JS, and related responses stop carrying secret-class credentials. Marketing pages and app shells can still use intentionally public keys. Billing keys, cloud secrets, and service tokens stay server-side. That is a cleaner story for security reviewers and for anyone parsing your public assets—including bots that do not care about your blog calendar.

Boundaries first

These notes assume you own the site, manage it, or have permission to test it. SlaySlop scans are read-only and are not a pentest. The check observes public bundles and responses; it does not rewrite your pipeline. Sibling checks cover different holes: Exposed files and admin panels for reachable env and backup files; Default credentials for vendor logins when ownership is verified.

Mistake 1: secret values behind a public env prefix

Frameworks make the failure convenient. NEXT_PUBLIC_, VITE_, and older REACT_APP_ prefixes tell the bundler to inline the value for the browser. That is correct for a publishable key. It is a direct leak for a secret key, service-role token, or private API credential.

The page still looks fine to a content crawler. Title and meta description can be perfect. The chunk still contains the token. SlaySlop's security product language calls this out as searching client bundles and responses for exposed keys, tokens, and credentials—exactly this class of ship.

# Authorized repo hygiene before a release build
rg -n "NEXT_PUBLIC_|VITE_|REACT_APP_" src/ app/ || true
# For each hit, ask: is this value safe in a public response?

Mistake 2: dumping config into window.__ENV__ or similar

Teams serialize a whole config object into the document so the client can "just read settings." One object later, a server-only field rides along. The HTML response itself becomes the leak, which matches the glossary's "bundles and responses" wording—not only .js files.

<!-- Pattern that still ships; never put secret fields here -->
<script>
  window.__ENV__ = {
    "API_BASE": "https://api.example.com",
    "STRIPE_KEY": "pk_live_publishable_ok",
    "ADMIN_TOKEN": "should-never-be-here"
  };
</script>

Fix the shape: only public fields enter the document. Secret fields stay on the server and move through privileged routes.

Mistake 3: treating staging secrets as harmless

Staging keys still open staging data, shared sandboxes, or billing in test mode that your contract still cares about. Public staging URLs get crawled. If the bundle exposes a token, the Client-side secrets observation still applies. Handoff decks that say "only staging" do not change what a public response contains.

Mistake 4: fixing source without busting the cached chunk

You remove the secret, merge, and forget that /assets/index-oldhash.js remains on the CDN with a long max-age. Search engines and users may keep fetching the old object. Security product guidance ranks urgent leaks first; an unreclaimed chunk keeps the leak live even after git looks clean.

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

Immutable plus a secret equals a rotation emergency, not a "next sprint" tidy task.

Mistake 5: confusing intentionally public keys with secrets

Publishable Stripe keys, maps keys restricted by HTTP referrer, and similar browser identifiers are meant to appear in client code when scoped correctly. Collapsing every match into the same panic ticket creates noise. Reading SlaySlop evidence with redaction still requires a human to classify: secret-class credential versus public identifier with missing restrictions.

Also watch source maps. A public .map next to a bundle can make an inlined value easier to recover from original source. The mistake is leaving both the value and the map on the public surface.

Pitfalls when prioritizing SEO work over secrets

AEO and SEO checklists obsess over titles, descriptions, structured data, and sitemap hygiene. Those matter. A leaked cloud key in a footer widget chunk will not show up as a missing meta description, and it can still burn the launch. Put Client-side secrets on the same pre-publish list as meta description and structured data—different parsers, same public HTML/JS surface.

Do not invent scan metrics or prices when you brief a client. Point at pricing for plans and at the glossary for what the check claims.

Related next step

When a mistake above is already live: rotate at the provider, remove the value from client-reachable output, purge or rehash cached assets, rescan. Use Client-side secrets and Security and secrets as the wording source so the ticket matches the product. If you want a ranked, redacted finding attached to the page, a permissioned pass through SlaySlop is enough to start the conversation without pasting raw keys into email.