Beautiful UI,default plumbing

• The project files can answer

  There is a hosting check for exactly this: on a detected Vercel deployment it asks whether the project’s own files — its secrets and its configuration — are reachable at a URL, what the edge cache did with a response that sets cookies, and whether the site is being served from the platform’s shared domain rather than its own.

• Cached responses and sessions

  An edge cache that stores a response carrying your session cookie can hand that response to the next visitor. It is rare, it is catastrophic, and it is one check that asks the cache a question and reads what came back.

• The banners say what you run

  A server header, an X-Powered-By, a framework fingerprint in the HTML. Together they tell a stranger the exact version your app is running, which is the sentence an exploit is written against. The scan reads the stack and reports the components with a public exploit against them.

• Source maps ship the source

  A build that leaves source maps published gives anyone the original files — comments, internal paths, and occasionally the value that was supposed to stay in the server. The check looks for them, and the secrets check reads what is in the bundle the browser downloads.

• Content-Security-Policy
• Vercel hosting security
• Cookie security flags
• Server header disclosure
• X-Powered-By disclosure
• Secrets in JavaScript
• Source maps
• Open redirect through URL parameters
• Tech stack inventory
• Mobile API rate limiting
• Canonical URL
• Duplicate titles and descriptions

Every one of these runs on every scan, whatever built your app. What each check looks at is on the full list.

• 01

  There is no v0 check in the scanner. There is a Vercel hosting check, because v0 apps usually deploy there — and if yours sits somewhere else, that check abstains and the other 84 run anyway.

• 02

  The scan sees the deployed site, not the project. It cannot read your Vercel dashboard, your environment variables, or the code between commits. Where a check needs a platform account it does not have, the report records that it could not look rather than guessing.

• 03

  It is not a penetration test. It never logs in, never submits anything of yours, never calls a state-changing endpoint, and refuses private and metadata addresses before a request leaves. The active checks run only on a domain you have proved you own.

• 04

  A clean scan is not a launch approval. It is 85 true statements about one URL on one day — which is a good deal better than a vibe check, and still not a substitute for reading the code you are about to send to customers.

1. Step 1

   Paste the URL you share

   The deployment URL or your own domain once it points there. No account connection, nothing to install.

2. Step 2

   It reads; it does not poke

   One fetch of the page answers most of the list. Where a check has to make more requests there are budgets: a five-second cap per fetch, a small number of probes per scan, robots.txt obeyed throughout.

3. Step 3

   Take the evidence and the prompt

   Every finding carries the header, the path or the status code behind it, plus a prompt for the same agent that wrote the app — the fix is pasteable rather than a lecture.

• Security scanner

  The full security pillar — headers, TLS, cookies, DNS and mail records, exposed paths, GraphQL, JWTs and hosting configuration.

• SEO scanner

  Generated pages duplicate metadata easily. This is the pillar that catches a title copied across every route.

• Lovable scanner

  The same list for apps built on a managed backend, where the risk sits in the database policies.