Your source can be clean and your live site still leaks.

A source scan proves your code is fine. It says nothing about what the bundler inlined, what the CDN stripped, or which old library version actually shipped. The Live Site Auditor fetches your deployed site from your own machine and reconciles it against source, then hands you two verdicts: secure to ship, and found by Google. The Live Site Auditor is part of IOnclad Pro.

What it actually does

This is the Pro, desktop-only half of the auditor. It does a native HTTP GET of your public deployed URL from your machine (no IOnclad server is ever in the loop), parses what comes back, and turns each signal into a finding that sits next to your local source results. The fetch is SSRF-guarded, runs only after you opt in to online checks, and degrades to a clean source-only report if anything fails.

Secrets in the live JS bundle Header drift vs source retire.js vuln libs SPF / DMARC / DKIM TLS handshake Exposed .git / .env SEO + indexability Performance (offline) Core Web Vitals (opt-in)

Why source-only misses things

The gap between what you wrote and what got served is where the worst pre-launch surprises live. Four of them:

1. Secrets that survived the bundler

You set a server key in an env var. The bundler inlined it into the client JS anyway, because it wasn't prefixed the way your framework requires, or because process.env.X got shipped to the browser. Now anyone can open devtools, read the bundle, and lift a live credential. Source review never sees it, because in source it looks like an env reference.

2. Headers stripped at the CDN

Your config sets a Content-Security-Policy, HSTS, and frame protection. Your proxy or CDN tier silently drops them in production. You think you're protected because the code says so. The browser disagrees. This drift is invisible until something fetches the real response.

3. Known-vulnerable JS that actually shipped

Your lockfile might be patched. The deployed bundle might still be an old jQuery or a library with a public CVE, because the build cache was stale or a vendored copy never got bumped. What runs in the user's browser is the thing that matters, and that's the thing this checks.

4. Email anyone can spoof

No SPF, no DMARC, no DKIM means anyone can send mail that claims to be from your domain. Your password resets land in spam and your phishing risk is wide open. None of that is in your repo. It's in your DNS.

The trap

"It passed the source scan" is not the same as "it's safe in production." A non-prefixed key the bundler inlined reads as a clean env reference in your code and as a downloadable secret in the deployed bundle. Only fetching the real site catches it.

The shape of a real incident

The classic vibe-coded deploy mistake looks like this:

# In source: looks like a normal env reference, passes review
const client = new Sdk({ key: process.env.SERVICE_SECRET });

# But the var was named SERVICE_SECRET, not VITE_/NEXT_PUBLIC_-safe,
# and the bundler inlined the literal value into the shipped chunk:
var client=new Sdk({key:"sk_live_9f3...redacted...8a"});  // in app.4f21.js

# curl your own deployed bundle and the key is right there,
# downloadable by anyone who views source.

How IOnclad catches it

The auditor runs your local source scan first (always offline), then runs the live half against the page it fetched and merges both sets:

Bundled-secret scan. It pulls the first-party JavaScript your site actually serves and runs the same Rust secret scanner over it. To keep false positives down it uses regex patterns only (no entropy detector on minified JS) and excludes keys that are public by design, like Stripe publishable keys and Firebase web config. The matched value is redacted before it ever enters a finding.
Header reconciliation. It compares security headers your source configures against the headers the live response actually returns, so a policy stripped at the CDN shows up as drift instead of passing silently.
Vulnerable libraries. It checks the JS it already fetched against a bundled offline vulnerability database (retire.js-style), with no extra network requests beyond the page itself.
DNS and email hygiene. It looks up SPF, DMARC, DKIM, and CAA through your system resolver, the same lookup your browser does, and flags missing records as Medium or Low. These never block the ship verdict.
Exposure probes and TLS. Content-verified checks for a publicly served .git or .env, an exposed API schema, missing security.txt, plus a native TLS handshake inspection.
Dual verdict. Findings map to pillars, and each gate blocks only on its own Critical findings: a Security gate ("secure to ship") and an SEO/indexability gate ("found by Google"), kept separate so one never contaminates the other.

IOnclad finds known patterns and common misconfigurations. It is not a guarantee or a full pentest, and the LaunchGuard intake is advisory, not legal advice.

How to fix what it finds

Rotate any bundled secret, then fix the build. If a server key reached the browser, treat it as compromised, issue a new one, and move the value behind a server route so the client never sees it.
Set security headers at the edge that actually serves the response, not just in app config, and re-audit to confirm they survive in production.
Bump the vulnerable library and rebuild clean, clearing stale build caches so the patched version is the one that ships.
Publish SPF, DMARC, and DKIM for your domain so your mail is trusted and your domain can't be spoofed.
Close exposed paths. Make sure .git, .env, and internal schemas are not publicly reachable on the deployed host.

Find every secret before someone else does.

Scan your code and full git history in under a minute. Free verdict, no signup, nothing leaves your machine.

Try the Browser Scanner → Download for Windows