Security Comparison

Public Security Scan vs. Secret Scanning

These are two different things that catch two different categories of risk. Understanding which one you need — and why you might need both — depends on how your app is built and deployed.

Public Website Scan

Checks what's exposed on your live deployed site — leaked keys in JS bundles, publicly accessible .env files, missing security headers, open admin panels. No source code access required. Finds risks attackers can exploit today.

Secret Scanning (Repo-Level)

Scans your source code repositories for committed secrets — API keys in git history, .env files committed by mistake, CI/CD configs with hardcoded credentials. Requires repo access. Prevents future leaks.

Side-by-side comparison

Aspect
Public Scan
Secret Scanning
What it scans
Your live deployed website — HTML, JavaScript bundles, HTTP headers, public file paths
Source code repositories — git history, working files, CI/CD configs
Access required
None — scans the public URL just like a browser would
Repository read access (GitHub App, local git, CI integration)
Finds keys bundled into frontend JS
Yes — fetches and scans all linked JS bundle files
Not always — depends on whether the bundled output is in the repo
Finds keys committed in .env files
Only if .env is publicly accessible at /.env
Yes — scans entire commit history
Checks security headers (CSP, HSTS, X-Frame-Options)
Yes — inspects live HTTP response headers
No — HTTP headers are not in source code
Checks for exposed .git directories
Yes — checks if /.git/ is accessible publicly
N/A — tests repo access, not public exposure
Checks CORS configuration
Yes — inspects live CORS headers
No
Detects secrets before deployment
No — only detects what is already deployed
Yes — can block commits containing secrets
Useful for existing deployed sites
Yes — immediate results, no setup
Yes, but requires repo access and setup
Useful for AI-built apps (Cursor, Lovable, Bolt)
Especially yes — AI tools often bundle secrets into client-side JS
Partially — depends on whether the AI tool uses a git repo

Common risks in AI-built apps — what each approach catches

Apps built with AI coding tools (Cursor, Claude, Lovable, Bolt, Replit) have a specific risk profile. Here's what each scanning type catches for each common vulnerability:

Secret hardcoded directly in a React component

AI coding tool generates const apiKey = 'sk_live_...' inline in a component file. Gets bundled into the public JS output.

Public scan: Caught
Secret scanning: Only if the source file is committed to a scanned repo

Secret in a .env file that got committed

Developer accidentally commits .env to git. Secret appears in git history.

Public scan: Only if .env is publicly served
Secret scanning: Caught

Missing Content-Security-Policy header

Framework ships without CSP headers by default. Common in Next.js, Vite, and Create React App projects.

Public scan: Caught
Secret scanning: Not caught

.env file accidentally deployed to public directory

Developer places .env in /public/ folder or configures server to serve it.

Public scan: Caught
Secret scanning: Not caught

Source maps deployed to production

Build tool generates .js.map files that expose original source code — including any secrets in comments or config.

Public scan: Caught
Secret scanning: Partially

Frequently Asked Questions

What is a public website security scan?

A public website security scan checks what is visible on your live, deployed website — the same information an attacker or a browser can see. It checks for exposed API keys in JavaScript bundles, publicly accessible .env files, missing security headers, open admin panels, CORS wildcards, and other vulnerabilities in your deployed site's public surface area. No source code access is required.

What is secret scanning?

Secret scanning audits your source code repositories for accidentally committed secrets — API keys, passwords, tokens, and credentials that were committed to version control. These tools scan git history and working directories to find secrets before they're pushed, or to retroactively find secrets already in commit history.

Can a secret end up on my live website even if it's not in my git repo?

Yes — this is the most common pattern with AI-built apps. An AI coding tool may write code that imports a secret key directly in a client-side file. The secret never appears in .env or gets scanned by repo-level scanners — it goes straight into a JavaScript bundle deployed to production and publicly accessible to anyone who visits the site.

Does AIExposureTool scan my source code?

No. AIExposureTool is a passive public website scanner — it only checks what is publicly visible on your deployed site. It fetches your HTML and JavaScript bundles (the same files a browser downloads) and scans them for exposed secrets. It has no access to your private source code or git history.

Run a free public security scan

19 passive checks on your live site — find exposed API keys, .env files, missing headers, and more in under 15 seconds. No signup required.

Public Security Scan vs. Secret Scanning — What's the Difference? | AIExposureTool | AIExposureTool