The code is yoursnow the review is too

• What the bundle gives away

  The client build is the last place a secret can hide and the first place a stranger looks. The scan reads the JavaScript your app ships for keys that were meant to stay server-side — and it knows the difference between a publishable key that belongs there and a service-role key that does not.

• Sinks the generator did not mean

  Inner HTML on a value from the URL. A query assembled by string concatenation. A redirect that trusts its parameter. These are the shapes a language model reproduces because they appear in a hundred tutorials, and each one is a named check rather than a hunch.

• The dependencies arrived uninvited

  A generated app installs what it needs and never removes it. The repository scan lists every package, ranks the vulnerable ones against known-exploited listings rather than raw CVE counts, and tells you whether the dependency is direct or three levels deep — which decides whether you can even fix it.

• Nothing recorded who did what

  The check most teams discover late: whether anything in the stack is logging. An app assembled in a week rarely has an audit trail, and the incident that follows is reconstructed from the attacker’s goodwill. There is a check for that, and a repository-side look at your infrastructure definitions too.

• Content-Security-Policy
• Cookie security flags
• CORS policy
• Exposed sensitive files
• Secrets in JavaScript
• Source maps
• Audit logging & monitoring exposure
• Open redirect through URL parameters
• SQL injection in query parameters
• DOM-based XSS sinks fed by URL input
• JSON Web Tokens published to anonymous visitors
• Tech stack & CVE

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 Cursor check in the scanner, and there could not be — Cursor is an editor, it does not host your app or touch your deployment. What runs is the same 85 checks every site gets, plus the repository scan if you install the GitHub App.

• 02

  The repository scan reads your code; the site scan does not. A secret that never made it into the build, a dependency behind a private registry, a policy file that is not deployed — each is visible from one side and invisible from the other. Running both is the point.

• 03

  It is not a penetration test and not a code review. 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. It will not tell you the architecture is wrong.

• 04

  A clean scan is a photograph. It is 85 true statements about one URL on one day — and the next merge is the one that would have needed it.

1. Step 1

   Paste the URL you shipped

   Wherever Cursor left it — your own host, a platform subdomain, a staging box you forgot was public.

2. Step 2

   Install the GitHub App for the repo

   A short-lived installation token, a clone, and pinned open-source scanners whose downloads are checked against upstream checksums before the image builds. Secrets, dependency vulnerabilities, license policy and an SBOM out the other end.

3. Step 3

   Take the evidence and the prompt

   Findings carry what was measured — the file, the version, the header — with a prompt written for the same agent that wrote the code, so the fix goes back the way the problem came.

• Security scanner

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

• Supabase checker

  If the app talks to Supabase, this is the free tool that asks the database what the publishable key can reach.

• How this compares

  What a website scan is, what it is not, and which other kind of tool answers the questions it cannot.