The 2 a.m. question after a vibe-coded launch
You accepted the AI’s PR, hit deploy, and went to bed. Then the thought lands: did a live Stripe key, a service_role token, or a database URL make it into the JavaScript that every visitor downloads?
That is not a theoretical worry. Browser bundles, source maps, and network responses are public. Anyone can open F12 and look. AuditHQ’s deep security scan does that look for you, on the site you own, and writes a report you can act on in the morning.
What “deep” means here
The scan is the same view a stranger already has: page source, client bundles, response headers, cookies, and request URLs from the load. It is not a pentest and it does not run exploits.
It flags leaked keys, missing CSP and HSTS, cookie flags, production source maps, an exposed .git directory, and a single light check for rate-limit headers on an API URL the page already called.
You see enough to fix it. Nobody else gets the secret.
A finding names the type and the last four characters — enough to grep your repo, never enough to use the value. The same redacted evidence feeds the project AI fix prompt, so a coding agent can patch headers and rotate keys without printing the credential.
Free plans prove the scan ran (counts and one header example). Pro unlocks every finding with the file or header to change.
How to sleep after you ship
1. Sign in and create a website project for the URL you just deployed.
2. Run the audit and open Deep security scan on the project page.
3. If a key finding appears, rotate it at the provider before you do anything else.
4. Copy the AI fix prompt and apply the header and cookie artifacts it names.
5. Re-run. When the Security score is strong and high findings are gone, you have evidence — not a guess — that the public surface is clear.