A client side secret scanner helps you answer one launch question: did any API key, token, webhook secret, or private config get shipped into public frontend code? It should crawl the deployed app, fetch JavaScript bundles, inspect rendered HTML, and flag anything a visitor's browser can download. Use it before production launch, after big frontend changes, and after changing build settings.
What a client side secret scanner finds?
Client-side secret scanning focuses on data that is already public from the browser's point of view. If the app sends it to HTML, JavaScript, source maps, static JSON, or network-visible config, assume an attacker can collect it.
The most useful checks look for:
- downloadable by anyone keys in JavaScript bundles, HTML, and static assets
- source maps left public with readable original source and comments
- frontend environment variables that include private server values
- test credentials accidentally shipped with demo or staging code
- Tokens in route data, build manifests, public JSON, or error payloads
- Webhook signing secrets, admin API tokens, and database connection strings
A scanner should not only search for obvious names like API_KEY. Good tools also recognize token shapes, entropy patterns, provider prefixes, and suspicious variable names around authentication, payments, storage, email, analytics, and internal APIs.
This matters because frontend exposure is different from a normal code repository leak. The secret may never appear in a public Git repository, but it can still be bundled during build time. A crawler can find it by behaving like a normal browser, then downloading the same public files your users receive.
For deeper bundle-specific review, compare this with a focused guide to scan JavaScript bundle checks.
Where frontend leaks happen?
Most client-side leaks come from build behavior, not from someone deliberately pasting a password into the UI. Modern frameworks make it easy to expose variables when a prefix marks them as browser-safe. The mistake is using that browser-safe prefix for a server-only credential.
A common unsafe pattern looks like this:
// Unsafe: bundled into public JavaScript
export const config = {
paymentSecret: process.env.PUBLIC_PAYMENT_SECRET,
internalApiToken: process.env.PUBLIC_INTERNAL_API_TOKEN
};
// Safer: keep secrets server-side
await fetch("/api/create-session", { method: "POST" });The safer pattern keeps the private value inside a server route. The browser asks your backend to perform the privileged action, and the backend uses the secret without returning it.
Leaks also happen through deployment previews. A founder may test an integration on a preview URL, then forget that the preview is publicly reachable. If the preview uses production credentials, the exposure is just as real as the main domain.
Other frequent failure points include public .env files, debug endpoints, static config files, sourcemaps, and verbose errors. A good scan should inspect both the homepage and deeper routes, because checkout, dashboard, onboarding, and admin paths often load different chunks.
If your concern is specifically exposed keys, use this practical checklist to detect exposed keys. For environment-file mistakes, review the public env exposure guide.
Run the scan before launch
Run the scanner against the deployed URL, not only the source code. Source review is useful, but the browser-visible output is the final truth. Build tools can inline values, tree-shake code unexpectedly, or preserve comments in files you did not inspect manually.
Use this launch sequence:
- Deploy to the exact environment you plan to ship.
- Crawl public pages, logged-out routes, and preview URLs.
- Fetch JavaScript chunks, source maps, manifests, and static JSON.
- Review findings by confidence, file path, and reachable URL.
- Rotate any confirmed secret before considering it fixed.
- Redeploy and rescan until the exposed value is gone.
Treat findings as evidence, not just warnings. Each result should show where it was found, what can be abused, and whether the value is likely active. A random high-entropy string in a test fixture is different from a live token used by an admin integration.
Still, never dismiss a finding only because it appears in a minified file. Minification does not hide secrets. Attackers routinely download all chunks, run pattern matching, and test whether tokens work against common APIs.
For a wider prelaunch review, run an AISHIPSAFE security scan across public attack surface, exposed files, and common launch risks. If you need broader crawling and more route coverage, use a deep scan before announcing the app.
Fix exposed secrets correctly
The first fix is not deleting the string from the bundle. If the value was public, assume it was copied. The correct first move is rotate first, then remove the exposure path, then redeploy.
A clean remediation usually follows this order:
- Revoke or rotate the exposed credential in the provider dashboard.
- Move the secret to a server-only environment variable.
- Replace direct browser calls with a backend route.
- Restrict the new credential by domain, IP, scope, or permission where possible.
- Remove public source maps if they reveal sensitive source context.
- Rescan production and previews after deployment.
Use rebuild and redeploy as a required step. Removing an environment variable from a dashboard may not change already-built static assets. Old chunks can remain cached by the hosting layer, browser cache, or CDN until you purge or invalidate them.
Also check whether the exposed token had write access. A read-only public analytics key may be acceptable by design. A storage admin token, payment secret, database URL, or internal service token is not. Apply least privilege so one future leak has limited blast radius.
For client-side credential exposure, teams often miss old preview deployments. Disable stale previews, protect them with authentication, or ensure they never use production secrets. A safe launch review includes the primary domain, preview URLs, marketing subdomains, and static asset hosts.
Finally, add the scanner to your release habit. Manual review catches obvious mistakes, but automated frontend leak detection is better at finding forgotten chunks, generated files, and routes that only appear after navigation.
Final launch check
Before launch, confirm run it on staging and production, no committed secrets, remove public source maps, and launch only after rotation for any confirmed leak. A scanner is most valuable when it checks what users can actually download, then verifies the fix after redeploy.
Faq
Can a frontend app ever contain secrets?
No private server secret should be in frontend code. Public browser keys can exist if the provider designs them for client use and restricts their permissions. Treat payment secrets, database URLs, admin tokens, webhook secrets, and service-role keys as server-only values that must never reach the browser.
Is source code scanning enough?
Source scanning helps, but it is not enough for launch review. Build systems can inline environment variables, preserve source maps, or generate static files that are not obvious in source review. Scan the deployed app because attackers inspect the final browser-downloadable output, not your intended architecture.
What should i do after finding a leaked key?
Rotate or revoke the key first, then remove the exposure from frontend code. Move privileged actions behind server routes, redeploy, purge cached assets if needed, and scan again. If logs show suspicious use, review provider activity and reduce the replacement key's permissions.
If you want a practical prelaunch check, AISHIPSAFE can scan your public app for exposed secrets and other launch risks before users find them.