A leaked api key scanner should inspect your public app surface before launch, not just your source repository. The main goal is simple: find keys that reached browser code, build artifacts, source maps, public config files, or exposed endpoints, then rotate them before users and crawlers see them. This check is especially useful for AI-built apps where generated code may mix server and client boundaries.
Run a leaked API key scanner
Start with the assets an attacker can fetch without logging in. A source repository scan is useful, but it misses secrets injected during builds, copied into client bundles, or exposed through deployment settings.
A good prelaunch scan should cover:
- Rendered HTML, including inline scripts and serialized config.
- JavaScript bundles, including hashed chunks and lazy-loaded routes.
- Source maps, because they can reveal original variable names and comments.
- Public config files, such as
.env,.env.local, JSON manifests, and debug output. - API responses, especially bootstrap endpoints that return client configuration.
- Static directories, where old build files and backups often survive.
Use a crawler-backed approach when possible. Modern apps hide sensitive strings in route chunks that only load after navigation. A homepage-only check can miss a payment page, admin route, onboarding flow, or test dashboard.
For a focused key workflow, pair this process with an API key exposure review. For wider launch coverage, AISHIPSAFE can run a security scan across public routes and common exposure patterns.
The most common mistake is treating environment variables as automatically private. In many frameworks, variables with client prefixes are intentionally bundled into browser JavaScript. The name may look like a secret, but the framework treats it as public configuration.
Client-visible variables should only contain values designed for public use. Any token that can create charges, read private records, send email, modify storage, or bypass rate limits belongs on the server.
Check common leak locations
A practical scan starts with the public build output. Look at what a browser, bot, or curl command can retrieve. Do not assume the deployed app matches the local codebase, because CI steps and hosting integrations often inject additional values.
Check these locations first:
- Build output folders like
dist,.next,out, andbuild. - JavaScript chunks loaded after clicking through critical flows.
- Source map files ending in
.map. - Public root paths such as
/.env,/config.json,/debug, and/backup.zip. - Client bootstrap data embedded in
window.__APP_CONFIG__or similar globals. - Serverless logs or error pages that echo request headers or config.
Here is a small CI check that fails a build when obvious high-risk token patterns appear in deployable assets. It is not a replacement for a scanner, but it catches simple mistakes early.
#!/usr/bin/env bash
set -euo pipefail
BUILD_DIR="${1:-dist}"
patterns='(sk_live_|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9_]{36}|xox[baprs]-)'
matches=$(grep -RInE "$patterns" "$BUILD_DIR" || true)
if [ -n "$matches" ]; then
echo "$matches"
echo "Potential exposed secret in $BUILD_DIR"
exit 1
fi
echo "No obvious secret patterns found"This script shows the basic shape of a check: scan the built artifact, print exact file locations, and fail before deployment. A dedicated secret scanner should go further by detecting more token families, reducing false positives, crawling runtime pages, and identifying source maps.
If your app ships large client bundles, run targeted JavaScript bundle checks. Bundles are one of the highest-signal places to inspect because they represent what users actually download.
A scanner should also classify findings by impact. A public analytics key may be acceptable. A live payment secret, cloud access key, database service role token, or private webhook signing secret is not acceptable in browser-accessible code.
High-impact tokens usually have one or more dangerous permissions: write access, billing access, user data access, infrastructure access, or authentication bypass. Treat those as urgent even if the app has not launched yet.
Fix and rotate exposed keys
Finding a secret is only the first half. The safe response is to remove the exposure, rotate the credential, verify the replacement, and monitor for use of the old value. Deleting the string from code is not enough.
Use this remediation checklist:
- Confirm public reachability by fetching the affected URL or bundle as an anonymous user.
- Identify permissions attached to the key, including scopes, project access, and billing rights.
- Revoke or rotate the credential from the provider dashboard.
- Move privileged calls server-side behind an authenticated endpoint.
- Redeploy clean artifacts after clearing build caches and old static files.
- Rescan production from the public internet.
- Review logs for suspicious use before rotation.
Rotation matters because the credential may already be cached. Search engines, package mirrors, browser extensions, monitoring tools, and random crawlers can copy public assets quickly. Assume the exposed value is burned once it appears in a public response.
Do not only rename variables. If the same value remains in a bundle under a new name, the risk is unchanged. Attackers search for token shape, provider prefixes, entropy, and nearby code context, not just variable names.
For AI-built apps, pay close attention to server/client boundaries. Generated code may place database queries, email calls, storage uploads, or payment operations in a client component because it satisfies the visible feature quickly. The app works, but the trust boundary is wrong.
A common before-and-after fix looks like this:
- Before: browser code calls a third-party API directly using a privileged token.
- After: browser code calls your backend, your backend validates the user, then uses the token server-side.
- Before: the client receives a service role key to read user data.
- After: the backend returns only the records that user is allowed to see.
Server-side proxying is not just about hiding the key. It lets you enforce authorization, rate limits, request validation, and audit logging before any privileged operation happens.
After cleanup, check the deployed domain again, not just the repository. Old files can remain on CDNs after a redeploy. Some platforms preserve previous build assets for rollback or cache efficiency. A public deep scan helps catch routes, chunks, and assets that a shallow check can miss.
Final prelaunch habit
Make exposed-key scanning part of every launch, preview deployment, and major feature release. The safest workflow scans the built app, rotates anything exposed, and verifies the live site after deployment. If you also scan the public website, you reduce the gap between what developers expect and what attackers can actually fetch.
Faq
What counts as a leaked API key?
A key is leaked when it appears in a place an unauthorized user can access, such as browser JavaScript, HTML, source maps, public files, logs, or unauthenticated API responses. Some publishable keys are designed for clients, but privileged tokens with write, billing, or private data access should never be public.
Should i rotate a key if my app has not launched?
Yes, rotate it if the value was deployed to any public or shareable environment. Preview URLs, staging domains, CDN caches, and build artifacts can still be crawled or forwarded. Rotation is faster than proving nobody saw the token, and it prevents delayed abuse after launch.
Can repository scanning find every exposed key?
No. Repository scanning only checks committed code. Secrets can be injected during CI, added through hosting dashboards, emitted into generated bundles, or exposed by runtime endpoints. A stronger workflow scans source, build artifacts, and the live public app before users arrive.
Run AISHIPSAFE before you ship if you want a practical exposure check across routes, bundles, headers, and public files without building your own scanning workflow.