Scan javascript bundle for secrets before app launch

To scan javascript bundle for secrets, review the exact files your browser downloads after build, not only your source repository. Search compiled assets, source maps, inline configuration, and public environment output for credentials, tokens, private endpoints, and admin clues. The practical goal is simple: confirm what is exposed, remove real secrets, rotate anything leaked, and add a repeatable prelaunch check.

What the bundle exposes?

A browser bundle is public by design. Any visitor can download it, prettify it, search it, and inspect network calls. Minification slows casual reading, but it does not protect credentials. If a value reaches the browser, assume it is visible.

The first pass is not about panic. A good review separates runtime configuration from real secret material. Some values are meant to be public, such as a publishable payment key or an analytics project identifier. Others should never appear in client code.

Look for these patterns first:

Exposed API keys with write, admin, or server-side permissions
Bearer tokens, webhook secrets, signing keys, or private JWT secrets
Database URLs, service-role credentials, SMTP passwords, or storage tokens
Internal admin routes, staging endpoints, debug panels, and test accounts
Source maps that reveal original files, comments, and variable names
Hardcoded feature flags that unlock restricted flows in the browser

A client-side secret scan should include every file served from your hosting platform, not just main.js. Modern apps often split code into dozens of hashed chunks. Leaks may hide in lazy-loaded admin modules, error pages, worker files, or old assets left behind by previous deploys.

For AI-built apps, the most common failure pattern is a model placing server examples directly into frontend code. A generated integration may work during testing because the key has broad permissions, but it silently ships the same key to every user. If that key can read customer data or create charges, treat it as a serious incident.

If your app is already public, run a public secrets scan before sharing links widely. If you want automated checks across exposed pages and assets, AISHIPSAFE can run a security scan against the live surface.

Run a focused bundle review

Start from the production build. Development files often contain noise, while deployed assets show the actual exposure. A frontend bundle audit works best when it follows the same path an attacker would use: fetch public files, inspect JavaScript chunks, then validate any suspicious values.

Use this quick local check after building:

bash

npm run build


grep -RInE '(sk_live_|AKIA[0-9A-Z]{16}|xox[baprs]-|BEGIN (RSA|OPENSSH) PRIVATE KEY)' dist || true
grep -RInE '(apiKey|secret|token|password|private_key|service_role)' dist | head -50
find dist \( -name '*.map' -o -name '.env*' \) -print

This command is not a complete scanner, but it catches obvious mistakes. The second grep intentionally produces false positives because variable names still matter. A file containing token may be harmless, but it tells you where authentication logic is happening.

A practical review flow:

Build production output using the same environment as deployment.
Search the built output for high-risk key formats and secret-like names.
Download deployed assets from the public URL and compare them with local output.
Inspect source maps, if enabled, for original .env, config, and server files.
Test suspicious values with minimal, read-only validation where safe.
Record each finding as public config, sensitive exposure, or uncertain.

Do not stop at string search. Many leaks appear as JSON blobs assigned to window.__CONFIG__, hydration data embedded in HTML, or route loaders that serialize environment variables. A JavaScript asset scan should include HTML, worker scripts, manifest files, and cached chunks.

Also check old deployments. Teams often fix the latest build but leave historical assets reachable by hash or preview URL. If a leaked chunk remains accessible through your CDN, attackers do not need your current homepage to reference it.

For deeper prelaunch coverage, combine this review with an AI app audit and a deep scan of public routes, headers, secrets, and exposed files.

Fix leaks safely

When you find a real credential in browser-delivered code, removing it from the bundle is only half the fix. Assume it was copied. Browser assets can be cached by users, CDNs, monitoring tools, search engines, and package analyzers.

Use safe rotation as the default response. Revoke the old credential, create a replacement with narrower permissions, deploy the server-side fix, and verify that the old value no longer works. If the key could access customer data, review logs for unusual use before and after the exposure window.

Most frontend leaks are fixed by moving privileged work behind a server-side proxy. The browser should call your own API route, and that route should use the private secret from server-only environment variables. The route must enforce authentication, authorization, rate limits, and input validation.

Before fix:

Browser sends requests directly to a third-party API with a private key.
Key permissions are broad because the frontend needs several operations.
Anyone can extract the key and call the third-party API outside your app.

After fix:

Browser calls your backend with the current user's session.
Backend performs only the allowed action for that user.
Secret stays server-side, and logs show who triggered each operation.

Apply least privilege to every replacement key. If a frontend identifier must be public, restrict it by domain, allowed origins, scopes, quotas, and environment. If the provider supports separate publishable and secret keys, only the publishable one belongs in client code.

For hosted apps, review platform-specific environment rules. Some frameworks expose variables with prefixes such as PUBLIC_, NEXT_PUBLIC_, or similar naming conventions. Those prefixes are not security labels. They are publishing instructions. Anything using them can land in the browser bundle.

If your app runs on a serverless platform, this related guide on Vercel API leaks explains the common pattern: secrets are safe only when they stay in server functions, not when they are imported by shared client modules.

Keep secrets out next time

A one-time review helps, but leaks usually return when teams move fast. Make bundle checks part of your release gate. Run them on every production build, especially after adding payments, email, storage, AI APIs, admin tools, or analytics.

A lightweight checklist is enough for most lean teams:

Check compiled assets before each launch or major deploy.
Block public source maps unless you intentionally need them.
Keep server and client config in separate files.
Review all variables with public prefixes.
Rotate any credential that ever reached the browser.
Add alerting for exposed .env, backup, and config files.

Source maps deserve extra attention. They are useful for debugging, but public maps can reveal original source, comments, internal file paths, and readable function names. If you need production error mapping, upload maps privately to your monitoring provider and avoid serving them to everyone.

Treat secret scanning as one layer, not the entire security review. A clean bundle does not prove the app is secure. You still need checks for access control, broken routes, unsafe headers, exposed admin pages, and production behavior. Pair bundle review with a broader prelaunch security checklist when shipping customer-facing software.

The safest rule is simple: anything shipped to the browser is public. Keep privileged credentials on the server, limit public identifiers, rotate leaks quickly, and repeat the check before launch. That gives you a realistic defense against one of the easiest AI-app mistakes to exploit.

Faq

Can minification hide secrets in JavaScript bundles?

No. Minification changes formatting and variable names, but the browser still needs the original string values to run the app. Anyone can download the file, search it, or use a beautifier. If a private credential appears in a minified bundle, treat it as exposed.

Are public API keys always a security problem?

Not always. Some providers intentionally issue publishable keys for browser use. The risk depends on permissions, origin restrictions, quotas, and what the key can access. A public identifier is acceptable only when the provider documents it as client-safe and you have restricted abuse paths.

Should i disable production source maps?

Usually yes, if they are publicly served. Source maps can expose original source structure, comments, and sensitive context even when no credential is present. If you need them for debugging, upload them privately to your error tracking system instead of hosting them beside public assets.

Want a quick outside check before you ship? Run AISHIPSAFE against your public app and review exposed secrets, risky files, and launch-blocking issues.