Website secret scanner: find exposed keys prelaunch

If you are about to launch, a website secret scanner should answer one question: did any credential become reachable from the public web? The useful scan checks rendered pages, JavaScript bundles, source maps, public files, and common config paths for API keys, tokens, private keys, and .env exposure. It does not replace code review, but it catches the leaks attackers can fetch without an account.

What a website secret scanner checks?

A good scan starts from the same position as an outside visitor. It requests public pages, follows discovered assets, inspects JavaScript, and probes predictable file paths. The goal is to identify publicly reachable credentials, not every secret that may exist in your private repository.

The highest value checks are usually simple and concrete:

client-side secrets in rendered HTML, scripts, JSON, or hydration data
API keys with recognizable prefixes, such as payment, email, cloud, and analytics keys
source maps that expose original source code and comments
public config files such as .env, .env.local, config.json, or credentials.json
Private keys, signing keys, webhook secrets, and long random bearer tokens
build artifacts that contain test credentials, staging endpoints, or old debug values

This matters most for AI-built apps because generated code often moves quickly from prototype to deployment. A helper library might read an environment variable on the server, then a refactor places the same value in a client component. The app still works, so the leak is easy to miss.

For a broader checklist of launch checks, pair this workflow with a secret scanning guide. If your app ships large client bundles, also run a focused JavaScript bundle scan because minification does not protect secrets.

The scanner should also distinguish between real credentials and noise. A string named API_KEY_EXAMPLE is usually low value. A token that matches a known provider format, appears in a production bundle, and can call an API is different. That finding deserves immediate rotation.

Triage findings without breaking launch

Not every match has the same risk. The triage step prevents two bad outcomes: ignoring a real leak because there are too many alerts, or delaying launch for harmless placeholders.

Start by asking three questions. Is the value reachable through unauthenticated access? Does it grant access to data, billing, infrastructure, email, or user accounts? Is the same value active in production, staging, or a third-party provider dashboard?

Use severity based on impact, not just pattern matching:

Critical: active private keys, cloud credentials, database URLs, payment secrets, or admin bearer tokens.
High: active API keys that can send email, read customer data, create charges, or modify production resources.
Medium: exposed staging credentials, webhook secrets, internal service URLs, or restricted public keys.
Low: examples, test strings, public client IDs, or keys that are intentionally browser-safe.

The most common mistake is treating all keys as equal. Some public keys are designed for browsers, but many are not. Payment publishable keys, map tokens with strict domain limits, and analytics IDs may be acceptable. A server-side secret, unrestricted API token, or service role key is not.

When a finding looks real, follow rotation priority. First disable or rotate the credential. Then remove it from the deployed asset. Finally, check logs for suspicious use. If the key touched production data, assume it was copied, even if you found it quickly.

For .env exposure, do not only delete the file. Review the hosting setup, deployment output, static file rules, and framework config. A public .env check helps catch the specific mistake where environment files are copied into the public directory or build output.

You can use a lightweight local check as a pre-filter, but do not rely on it as your only control:

bash

set -euo pipefail
BUILD_DIR="${1:-./dist}"
grep -RInE "(sk_live_|ghp_[A-Za-z0-9_]{36}|AKIA[0-9A-Z]{16})" "$BUILD_DIR" || true
grep -RInE "-----BEGIN (RSA|OPENSSH) PRIVATE KEY-----" "$BUILD_DIR" || true
find "$BUILD_DIR" -type f \( -name ".env*" -o -name "*.pem" -o -name "credentials*.json" \) -print

This catches obvious patterns in a build directory. It does not crawl deployed routes, inspect dynamic responses, or validate whether a key is active. Treat it as a guardrail, not a full external scan.

Add scanning to release workflow

The best time to scan is after production-like build, before public announcement. That is when bundling, environment injection, static export, CDN rules, and route generation have already happened. Repository scanning alone can miss these deployment-specific leaks.

A practical release workflow looks like this:

Build the app using production settings.
Deploy to a preview or staging URL that matches the real hosting stack.
Crawl public routes, scripts, maps, JSON endpoints, and static assets.
Probe common secret paths, including .env variants and backup files.
Review matches by severity and prove exploitability only in safe, authorized ways.
Rotate active credentials, redeploy, and scan again.
Store a short record of findings, fixes, and remaining accepted risks.

The key operational rule is fix the source. If a token appears in a bundle, do not patch only the built file. Find the component, config, or build step that injected it. Otherwise the next deploy will recreate the same exposure.

Add a release gate for scan after build. For small teams, that can be a manual checklist before launch. For larger teams, make it part of CI or deployment approval. The gate should fail on confirmed secrets, not every uncertain string, or developers will route around it.

Expect false positives. Random IDs, hashes, public SDK keys, and placeholder values can look secret-like. The answer is not to disable scanning. The answer is to review noisy matches, allowlist known-safe values narrowly, and keep provider-specific patterns strict.

OWASP provides a useful baseline for handling credentials in its Secrets Management Cheat Sheet. Use it for storage and rotation principles, while external scanning covers what actually became public.

Ship with fewer leaks

A secret exposure check is one of the fastest launch-risk reducers. It finds mistakes that attackers can automate, such as exposed .env files, leaked service tokens, and client-side credentials. Use short-lived tokens where possible, restrict keys by domain or scope, and rescan after every meaningful deployment.

If a scan finds a real production credential, treat it as exposed. Rotate it, remove the root cause, review access logs, and run the scan again before you ship.

Faq

Can this replace repository secret scanning?

No. Repository checks find secrets before they are deployed, while public scanning finds what actually reached the website. You need both for stronger coverage. A repo can look clean while a build step, environment injection mistake, source map, or static file rule exposes a credential after deployment.

Should public browser keys be removed?

Not always. Some keys are meant to appear in browsers, such as publishable payment keys or analytics IDs. The risk depends on scope, restrictions, and provider rules. Confirm whether the key can access sensitive data, trigger costs, change resources, or bypass server-side authorization.

How often should i scan after launch?

Scan before launch, after major deployments, after framework or hosting changes, and whenever secrets are rotated. Weekly scanning is reasonable for active products. Also scan immediately after emergency fixes, because rushed changes often introduce copied config files, debug endpoints, or accidental frontend exposure.

AISHIPSAFE can help you run a fast security scan before launch. For deeper coverage across public routes, assets, and risky files, use a deep scan before sharing your app widely.