Exposed secrets
Looks for high-confidence server-side credential patterns in public HTML and linked client assets. Public Supabase anon keys, Firebase web config, Stripe publishable keys, and reCAPTCHA site keys are not labeled secrets.
Live URL scan · passive and read-only
Paste your app's URL. We'll check for the security gaps that AI coding tools most often leave behind — exposed secrets, missing protections, risky data-access setups. Results in seconds. No signup.
01Fetch only public browser assets
02Keep credentials out of results
03Separate signals from proof
04State every important limit
No login · no exploit payloads · no table queries · no active RLS test
What this check can tell you
Looks for high-confidence server-side credential patterns in public HTML and linked client assets. Public Supabase anon keys, Firebase web config, Stripe publishable keys, and reCAPTCHA site keys are not labeled secrets.
Reads Content Security Policy, HSTS, MIME sniffing, framing, referrer, and browser-permission headers. Missing headers are hardening gaps, not automatic proof of exploitation.
Recognizes supported public BaaS markers and explains why server-enforced RLS or security rules deserve review. It never queries a table or collection.
Checks HTTPS and obvious mixed-content references, then records ordinary public framework fingerprints to help scope a deeper authorized review.
It reads the public page, response headers, and up to six same-origin JavaScript or CSS assets linked by that page. It checks for high-confidence secret patterns, baseline security headers, data-layer signals, HTTPS consistency, and supported framework fingerprints.
It is passive and read-only. It does not log in, send attack payloads, query databases, enumerate private paths, exploit a finding, or actively test row-level security. Scan only apps you own or have permission to test.
The scanner does not persist page bodies, matched secret values, or findings. Analytics receives only a one-way hash of the target hostname plus coarse funnel data. A public scorecard contains aggregate counters only and never the target URL or finding detail.
No. A clean result means no surface issues were found in this limited, outside-only check. Business-logic flaws, authenticated access issues, server-side code, and exploit validation require a deeper authorized assessment.