Check 12 of 12 · Security

Secrets in JavaScript: leaked keys in the page's own script bundles

What the secrets check scans, why a secret key in client-side JavaScript is public the moment the page loads, and what a public permalink shows and hides.

What it checks

We fetch at most ten of the script bundles the page itself references (same origin, in document order, respecting robots.txt) plus inline scripts, and scan them for the formats of known secret credentials: live payment keys, cloud access keys, private tokens. We never guess paths, and we never request scripts the page does not reference.

Why it matters for search engines

This check has no search effect. It is here because agencies are asked to keep client sites safe, and a leaked key is the kind of thing a client hears about from their payment provider first.

Why it matters for AI assistants

AI crawlers read the same bundles. Anything in client-side JavaScript is public to every reader, human or automated, and can end up quoted in places you do not control.

How to fix it

Rotate the leaked key immediately and treat it as compromised, then remove it from the bundle. Secret keys belong on the server; the browser should only ever hold publishable keys, which providers issue for that purpose.

What a public permalink shows for a finding
Security: 1 finding. The location is not shown on a public link.

What quietwatch reports

ok with the number of bundles scanned and how many were skipped and why. fail with the number of findings. On a public permalink the file, line and column of a finding are never shown, only that one exists; the full detail is for verified owners in the Pro plan. unknown when the page could not be fetched.

Sources

All twelve checks · Previous: Domain registration

See what your site reports for secrets in javascript

Check your site