for Cursor apps

Cursor app security check

No signup 路 no repo or GitHub access needed 路 passive, read-only checks 路 results in under a minute

See a sample report

Built your app with Cursor? Paste your live link and get a free score before you share it. Under a minute, no sign-up.

Only scan apps you own or have permission to scan.

why.txt

What to check on an app built with Cursor

Cursor writes real code that you deploy yourself, usually to Vercel, Netlify or your own server. That means the security settings are yours too: env vars, headers, build output and what ends up in the browser.

The most common slip is a secret key that lands in frontend code, for example in a NEXT_PUBLIC_ or VITE_ variable, a config file the agent created, or a file that got deployed by accident. Anything the browser downloads can be read by any visitor.

what_we_check.log

What the free scan checks

  • Leaked keys in your frontend

    Your page HTML and up to 15 of your own JavaScript files are checked for Stripe live secret and restricted keys, OpenAI, Anthropic, AWS, GitHub, Slack and Resend keys, Google API keys and private key blocks. Anything found is masked in the report.

  • Supabase service_role key

    A Supabase service_role key in your client code is flagged as critical. That key skips Row Level Security entirely.

  • Files left on the server

    Things like /.env, /.env.local, /.env.production, /.git/config, .npmrc, docker-compose.yml, backup files, and package.json or lockfiles.

  • Public source maps

    We check whether a source map for one of your JavaScript files can be downloaded, which would expose your original source.

  • Security headers and CORS

    HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and wildcard CORS with credentials.

checklist.txt

Cursor pre-launch checklist

  1. Keep secrets on the server. Only publishable keys belong in NEXT_PUBLIC_ or VITE_ variables. Stripe secret keys, OpenAI keys and a Supabase service_role key go in server-only env vars.
  2. Check what the agent added. Search your repo for keys the agent may have pasted into code, tests or config files, and move them to env vars.
  3. Keep .env out of git and out of the build. Add .env files to .gitignore and make sure nothing copies them into your public or dist folder.
  4. Turn off public source maps. Make sure production builds don't serve .map files publicly unless you mean to.
  5. Add security headers. Set HSTS, X-Content-Type-Options, Referrer-Policy and a frame policy in your host or framework config.
  6. Lock down your database. If you use Supabase, turn on Row Level Security for every table and test as a second user.
  7. Run the free scan. Fix anything critical or high first, then rotate any key that was ever exposed.
faq.txt

FAQ

Does it work for any stack Cursor wrote?
Yes. It checks the live site, so it works for Next.js, Vite, React, plain HTML or anything else, on any host. Paste the public URL people use.
Does it read my repo or my Cursor project?
No. It only sees what your live site serves to a logged-out visitor. It never connects to your code, your editor or your accounts.
Do I need to sign up?
No. Paste your link, confirm it's your app (or you have permission), and run it. Adding your email is optional and shows the risk breakdown and one problem by name.
What does it cost?
The scan and your score are free. The full list of findings with a fix for each is a one-time $9, or $29 for a pack of 10 reports.
Does it attack my site?
No. It only makes ordinary read requests, sends no exploit payloads, and never logs in or submits forms.
What doesn't it check?
Pages behind a login, third-party scripts, your server code and your database policies directly. A good score is not a guarantee of security.

Run the free scan