Scan public website for secrets before app launch safely

If you need to scan public website for secrets, start by checking everything a browser, crawler, or attacker can reach without logging in. That means HTML, JavaScript bundles, source maps, public files, API responses, robots.txt, and common misconfigured paths. The goal is simple: find credentials that should never be public, verify whether they are real, revoke them fast, then prevent the same leak from returning.

This is a narrow but high-impact check. A single exposed token can turn a harmless launch bug into database access, account takeover, payment abuse, or cloud resource theft.

What exposed secrets look like?

Public website leaks usually come from build output, not from a hacker breaking in. Modern apps push large JavaScript bundles to CDNs, expose preview deployments, and include generated files that developers forget to review.

Look for these common patterns first:

API keys in JavaScript that were meant for server-side calls
Public .env files left in a web root or static folder
Source maps with comments showing tokens, endpoints, or internal paths
Bearer tokens in responses from debug or bootstrap endpoints
Cloud credentials such as access key IDs and private secret strings
Webhook signing secrets exposed through config objects or logs
Admin URLs and staging links referenced in public bundles

Not every key in frontend code is automatically dangerous. Some publishable keys are designed for browsers. The risk depends on scope, permissions, domain restrictions, rate limits, and whether the key can access private data.

A practical review separates safe public identifiers from usable credentials. For example, a publishable payment key may be expected, while a secret payment key is critical. A map tile token may be acceptable if restricted by domain, but risky if it allows billing abuse from any origin.

For a focused walkthrough on one of the most common leak types, review the guide to public .env exposure. If your main concern is keys embedded in pages and bundles, the exposed API keys checklist is also directly relevant.

How to scan public website for secrets?

Start with the public attack surface, then work inward. You are not trying to exploit the app. You are checking what the site already serves to anonymous users.

A good first pass includes the homepage, route-level HTML, JavaScript assets, static files, API responses used during page load, and cached deployment artifacts. Include production, preview, staging, and custom domains if they are publicly reachable.

Use both automated scanning and manual review. Automated checks are better at breadth. Manual review is better at context, especially when deciding whether a key is actually dangerous.

A small local check can quickly collect public JavaScript and search for obvious patterns:

bash

SITE="https://example.com"
curl -s "$SITE" \
  | grep -oE 'src="[^"]+\.js[^"]*"' \
  | cut -d'"' -f2 \
  | sed "s@@BLOGTOKEN0@@
  | while read js; do
      echo "Checking $js"
      curl -s "$js" | grep -Ei "api[_-]?key|secret|token|Bearer|sk_live|AKIA"
    done

This is not a complete detector, but it shows the workflow. Pull the assets, inspect what the browser receives, and flag values that look like credentials. A dedicated security scan should go deeper by crawling routes, following redirects, inspecting public files, and grouping findings by risk.

Use this checklist for the first scan:

Crawl public routes from the homepage, sitemap, and known marketing pages.
Fetch JavaScript bundles and search for token-like strings and sensitive names.
Check source maps such as .map files linked from bundles or deployed beside them.
Probe common files including .env, .env.local, config.json, and backup names.
Inspect API responses loaded before authentication, especially bootstrap endpoints.
Review preview domains because they often bypass production hardening.
Record evidence safely without copying full secrets into tickets or chat.

Be careful with secrets in logs too. If your scanner, terminal, or CI job prints complete credentials, you may create a second leak while investigating the first. Store only a partial fingerprint, such as the first 4 and last 4 characters, plus the URL and file path.

Confirm and fix findings

A finding is not complete until you answer three questions: is the value real, what can it access, and where did it come from? Treat obvious private keys, secret tokens, and cloud credentials as compromised even if you cannot confirm use.

Use safe verification only. Do not run destructive API calls, access customer data, or test actions beyond what your team owns. For many providers, the safest proof is metadata validation, permission review in the provider console, or checking whether the key format matches a known secret type.

Fix order matters. Start with active credentials that grant write access, billing access, production database access, or admin privileges. Then handle lower-scope tokens, internal URLs, debug metadata, and source disclosure.

A practical response looks like this:

Revoke or rotate first if the token could grant private access.
Remove the source leak from code, config, build output, or static storage.
Redeploy clean artifacts so old bundles and maps stop being served.
Purge CDN caches if the leaked file may still be available at edge locations.
Check access logs for suspicious requests to the leaked path or asset.
Add a prevention control before closing the issue.

Do not rely on deleting a file from the latest deployment if old assets remain available. Many frontend platforms serve hashed bundles for a long time. Attackers and search engines can still request an old asset if the URL was indexed, logged, shared, or referenced by a cached HTML page.

For higher-confidence reviews, use a deep scan that checks public files, client-side assets, and hard-to-spot exposure patterns together. Secret exposure rarely appears alone. It often pairs with open debug routes, verbose errors, or weak security headers.

Keep leaks from returning

The durable fix is to change how secrets move through the app. Browser code should receive only public identifiers, short-lived session data, and values explicitly designed for client-side use. Server-side secrets should stay in server runtimes, backend functions, or managed secret stores.

For AI-built apps, review generated code carefully. Code assistants often wire integrations quickly, but they may place service-role keys, database URLs, or admin tokens in client utilities because the happy path works in local testing. That creates frontend secret leaks when the app is bundled.

Add these controls before launch:

Server-only boundaries for payment, database, email, and storage operations
Environment variable naming rules that distinguish public and private values
Pre-commit secret detection for local development mistakes
CI scanning on builds before assets are deployed
Domain restrictions for keys that must run in browsers
Least-privilege credentials for every integration
Short rotation playbooks so leaks are fixed in minutes, not days

Framework conventions can help, but they are not a substitute for review. A variable prefix may mark a value as public, but it cannot decide whether that value should be public. That decision belongs to the developer and security review.

Also scan after major changes. New integrations, analytics scripts, payment flows, AI features, and file upload systems often introduce fresh configuration. A clean result last month does not prove today’s deployment is safe.

A launch-ready site does not just hide secrets. It makes accidental exposure difficult, limits what any single key can do, and gives the team a fast way to detect and rotate leaks. Run the check before launch, after large releases, and whenever you add a new third-party integration.

Faq

Can a public website scan find every secret?

No. It can only find values exposed through public pages, files, assets, and unauthenticated responses. It will not see secrets stored safely on the server or inside private repositories. Pair public scanning with repository checks, CI secret detection, and cloud permission reviews for stronger coverage.

Are frontend API keys always unsafe?

Not always. Some keys are intentionally public, such as publishable payment keys or restricted browser tokens. They become risky when they allow private data access, server-side actions, billing abuse, or unrestricted use from any domain. Always check permissions, restrictions, and provider documentation before closing a finding.

What should i do if i find a live secret?

Rotate or revoke it immediately, then remove the leak and redeploy clean assets. Purge caches if needed, review logs for access, and create a prevention task. Do not paste the full secret into tickets, chat, or documentation while coordinating the fix.

AISHIPSAFE helps teams check public app surfaces before users and attackers find mistakes. Start with a focused scan, fix confirmed leaks, then repeat it whenever your launch surface changes.