Public secret exposure check before your app launch

A public secret exposure check answers one launch question: can anyone on the internet retrieve credentials from your app? Scan the deployed site, rendered pages, JavaScript bundles, source maps, public files, and configuration endpoints before users arrive. Treat every finding as urgent because even read-only keys can expose data, drain quotas, or help attackers map your backend.

Public secret exposure check scope

The goal is not to prove the whole application is secure. The goal is narrower: find secrets that became reachable from the public internet. That includes anything a browser, crawler, or unauthenticated request can access after deployment.

Start with these areas:

Browser-readable output, including HTML, scripts, JSON hydration data, and inline config.
Runtime configuration, especially values injected during static builds or edge deployment.
Public files, such as .env, backups, logs, debug dumps, and old build artifacts.
Deployment artifacts, including source maps, asset manifests, and framework metadata.
Third-party tokens, such as payment, email, analytics, storage, AI, and database keys.

This check is especially useful for AI-built apps because generated code often mixes server and browser boundaries. A tool may place a token in a shared config file, then import that file into a client component. The code works in preview, but the secret ships to every visitor.

A good result is not simply no matches. A good result means every public asset was checked, every suspicious value was classified, and every real secret was rotated or restricted. If you need a broader launch review, run a security scan alongside this secret-focused pass.

Where secrets usually leak?

Most leaks are boring, which is why they are missed. They happen during normal development, not during an advanced attack. The common pattern is a developer adds a key locally, the app builds successfully, and the deployment system makes the value public.

The highest-risk examples are client-side secrets embedded in JavaScript. If a token appears in a bundle, source map, or rendered HTML, it should be assumed compromised. Browser dev tools, search engines, archived pages, and automated scanners can all retrieve it.

Another frequent pattern is hardcoded secrets added as temporary fixes. A developer may paste a database URL, admin token, webhook signing secret, or service role key into code to unblock a demo. Later, the line remains in a route, test file, or config module.

Watch for exposed API keys in framework config. Some variables are intentionally public, such as browser-safe analytics IDs. Others are not. Prefixes like NEXT_PUBLIC, VITE, PUBLIC, or client config exports can move sensitive values into the frontend.

Also check source maps. They are useful for debugging, but they may expose original source paths, comments, old endpoints, and sometimes literals removed from the minified file. If source maps are public, scan them like production code. For deeper bundle guidance, see how to scan JavaScript bundle before release.

A quick local sweep can catch obvious problems before you deploy:

bash

mkdir -p /tmp/app-scan
cp -R dist public .next/static /tmp/app-scan/ 2>/dev/null || true
grep -RInE '(sk-[A-Za-z0-9_-]{20,}|AKIA[0-9A-Z]{16}|xox[baprs]-)' /tmp/app-scan || true
grep -RInE '(service_role|private_key|client_secret|DATABASE_URL)' /tmp/app-scan || true
find /tmp/app-scan -iname '*.map' -o -iname '.env*' -o -iname '*backup*'

This is not a complete scanner. It is a sanity check that finds obvious public credential leaks before a crawler or attacker does.

How to run the check?

Run the review against the production-like URL, not only your repository. Many leaks are introduced by build-time injection, hosting configuration, or static export behavior. The deployed artifact is the source of truth.

Use this practical workflow:

Build production assets locally and scan the output directory before deployment.
Crawl like a user against staging or production with no authentication.
Inspect JavaScript bundles for token formats, secret names, and suspicious endpoints.
Check known public paths such as /.env, /.env.local, /config.json, /debug, /backup.zip, and /server.log.
Review source maps and disable public access unless you intentionally need them.
Confirm server boundaries by verifying sensitive calls run only in backend routes.

For public websites, also inspect framework-specific files. Single page apps often expose asset manifests. Server-rendered apps may include hydration data. Static exports can copy files from folders that were meant to be private.

When AISHIPSAFE performs a deep scan, the useful part is not only matching secret patterns. The scan should follow public links, pull assets, inspect reachable files, and flag values that look actionable. A token-like string in a comment is less severe than a live cloud key, but both deserve review.

If you already know a frontend key may have shipped, use a focused guide on a frontend API key leak. If the concern is environment files, review public .env exposure because exposed env files usually contain multiple secrets, not just one.

Do not rely on robots.txt, obscure filenames, or lack of links. Attackers request common paths directly. They also search indexed caches, JavaScript chunks, and old deployments. If the file is publicly reachable, treat it as public.

Fix and verify findings

Fixes should follow the severity of the exposure. If a real secret was public, removal is not enough. Assume the value was copied and rotate it. Logs, browser caches, build artifacts, CDN caches, and search indexes may preserve old content after the deployment is updated.

Use this order of operations:

Revoke or rotate the exposed credential.
Remove the secret from browser-delivered code and public files.
Move sensitive operations to server-side routes or backend jobs.
Add provider restrictions, such as domain, IP, scope, quota, and read-only access.
Purge CDN caches and redeploy clean assets.
Re-scan the public URL and archived build output.

Some keys are allowed in browsers, but they still need constraints. A publishable payment key or analytics ID is different from a server token. The safer rule is simple: if the credential can modify data, read private data, spend money, send messages, or bypass authorization, it must not be public.

Pay attention to false reassurance from naming. A variable called PUBLIC_API_URL is usually harmless. A variable called PUBLIC_SUPABASE_ANON_KEY may be acceptable only if row-level security is correct. A variable called PUBLIC_SERVICE_ROLE_KEY is a critical issue because the name reveals the mistake.

Verification should be evidence-based. Save the affected URL, asset path, token prefix, provider, rotation time, and re-scan result. This creates a small audit trail for the launch decision and helps prevent the same mistake in the next deployment.

Before shipping, make this check part of the release gate. Public secret exposure is fast to create and expensive to clean up. A narrow scan of public assets, files, and bundles gives you a clear yes-or-no answer before real users and automated crawlers arrive.

Faq

What counts as a public secret?

A public secret is any credential, token, private URL, signing key, or sensitive configuration value reachable without authorization. It can appear in HTML, JavaScript, source maps, public files, logs, or cached assets. If a normal browser request can retrieve it, treat it as exposed.

Are frontend API keys always unsafe?

Not always. Some keys are designed for browsers and limited by provider rules. They become unsafe when they grant private data access, write permissions, billing actions, or backend privileges. Even browser-safe keys should use restrictions, quotas, and monitoring to reduce abuse.

Should i rotate a key after removing it?

Yes, if the key was publicly reachable. Removing it from the app stops future exposure, but it does not prove nobody copied it. Rotate the credential, update the backend, purge caches, and review provider logs for unusual use after the suspected exposure window.

Run AISHIPSAFE before launch if you want a focused external scan for secrets, risky public files, and common production exposure mistakes.