Provider secret keys in JavaScript
Server API keys for payment, AI, cloud or source-control providers can be extracted from a bundle by any visitor.
Frontend secret exposure
Find credentials your frontend may have made public
BoringSec fetches the deployed page and bounded same-origin JavaScript assets, identifies supported credential formats and masks values in evidence. Public-by-design identifiers are not automatically called leaks.
A URL scan covers what the browser receives. A separately connected repository is needed for server-only files and code that never ships to the client.
Run scans only on systems you own or are authorized to assess. Deep engines require verified authorization and may remain unavailable for a target.
report / sample findingIllustrative
Critical
Example report structure
Stripe secret key exposed in a JavaScript bundle
- Evidence
- A value matching a supported Stripe secret-key format appears in a fetched same-origin asset. The report masks the credential and identifies the source asset.
- What it means
- Stripe secret keys are server-only. A public bundle makes the credential retrievable without authentication.
- Fix and verify
- Revoke and rotate the key in Stripe, remove it from client code and source history, move provider calls server-side, redeploy and rescan every shipped asset.
This is an illustrative finding, not a result for your application. Live reports show the scanner, evidence state and coverage limits for the actual target.
Common risk paths
What deserves a closer look
These are risk patterns relevant to API key exposure projects—not claims that every project has them. A finding appears only when a scanner returns supporting evidence.
Database credentials and privileged tokens
Connection strings, signing secrets and service-role credentials can turn a frontend leak into direct data access.
False alarms on publishable identifiers
Stripe publishable keys, analytics IDs and Supabase anon keys can be intentional. Classification and surrounding evidence matter.
Honest coverage
What each scan surface can prove
URL evidence, connected source and authorized deep engines answer different questions. BoringSec keeps those sources separate and shows partial, blocked and unavailable states instead of turning an untested surface into a pass.
Read the public methodologyPublic HTML and same-origin bundles
Scans the initial document and bounded same-origin JavaScript assets. Cross-origin or oversized assets are omitted and recorded as partial coverage.
Supported credential patterns
Recognizes supported formats and contextual patterns for provider credentials, private keys, database URLs and privileged backend tokens.
Masked evidence
Reports the source asset and a masked representation rather than returning a reusable credential in the UI, logs or public report.
Repository-only exposure
A separately connected repository can add committed environment files, credentials and server-side source that a deployed bundle scan cannot see.
From observation to verification
A report built for the next action
- 01
Observe
Inspect the public response path and start eligible background engines.
- 02
Verify evidence
See what was observed, by which scanner and with what confidence.
- 03
Fix in context
Use a concrete remediation path and the API key checker-relevant context.
- 04
Retest
Run a fresh assessment; monitoring can detect later regressions separately.
Questions before you scan
Does the checker test whether a discovered key still works?
No. It does not authenticate to third-party providers with discovered credentials. It reports supported secret-shaped evidence and leaves revocation and provider-side incident review to the owner.
Are NEXT_PUBLIC and VITE variables always unsafe?
No. Those prefixes mean a value is intended to reach the browser. The value must still be a publishable identifier rather than a server secret. BoringSec evaluates supported formats and context instead of flagging every public variable.
Will the report display my complete key?
No. Supported secret evidence is masked. BoringSec records enough context to locate the source without intentionally reproducing a reusable credential.
Does a clean result prove no keys exist?
No. Unsupported formats, runtime-generated values, inaccessible assets, server-side files and source outside the deployed bundle remain out of scope. Partial and unavailable coverage is shown explicitly.
Check the deployed application, then verify every fix
Start with the public URL. Add source or authenticated context only when you choose to expand coverage.
Start a security scan