How the keys in public scripts check works
Everything in your pages and script files is downloaded by every visitor's browser, and anyone can read it. Sometimes a developer leaves a key in there that was meant for the server only: a payment provider's secret key, a cloud access key, a token for a code repository. Automated tools search the web for exactly these. This check looks for them first.
What it reads
- Your home page and up to two linked pages, already fetched for other checks.
- Up to 8 of your site's own script files, the ones on your own domain that those pages load, each read up to 1 MB. Scripts loaded from other companies' servers are not fetched: a key in someone else's file is not yours to change.
- Up to 4 source maps those scripts point to, each read up to 2 MB. A source map is a file that turns minified code back into the readable original, often including the original source text.
What it reports
- A secret key in a public file. The check recognises key formats that are secret by design, following the rules of the open-source gitleaks project: for example Stripe secret keys, AWS access keys, GitHub and GitLab tokens, Slack tokens and webhooks, OpenAI and Anthropic API keys, SendGrid keys, private key blocks and Supabase
service_rolekeys. Keys that are meant to be public, such as Stripe publishable keys, Google browser API keys and Supabase anon keys, are not reported. Documentation examples are skipped. - Public source maps. Your scripts' readable original code can be downloaded. That is not a secret leak in itself, but it hands anyone your code's structure and comments.
A key we find is never stored or shown. The report names the kind of key, the part of it that is the same for every key of that kind (such as sk_live_), its length, and the file it was in.
What it cannot see
- Keys in script files on other domains, in files the pages do not link to, or beyond the size limits.
- Keys used only on your server. Those are where keys belong.
- Whether a key still works. We never try a key: that would be using it.
What to do with the result
Treat any reported key as known to others. Ask your developer to revoke it at the provider and create a new one, then move it to the server side, where visitors cannot download it. Removing it from the file without replacing the key is not enough, because copies of the old file may already exist. Source maps can usually be switched off in the build settings, or kept off the live site.
See what this looks like on your own site: a free, passive check in about two minutes.
Check my websiteEverything this check can report
- CriticalSecret key in a public file
- MinorJavaScript source maps publicly readable
Severity is fixed per finding in our code and never set by the AI that writes the report text. How severity becomes a score is on the methodology page.
The other checks
- How the security headers check works · The instructions your server sends to browsers with every page.
- How the cookies check works · Whether the cookies your site sets are protected on the way and in the browser.
- How the secure connection check works · Your certificate, the encryption your server accepts, and whether visitors are moved to https.
- How the email and DNS check works · The public DNS records that stop fake email in your name, and addresses pointing to services you no longer use.
- How the technology check works · What your site is built with, worked out from what it shows publicly.
- How the vulnerability wave check works · Whether what we can see matches a major vulnerability in the news.