Pro Logica

    Cursor App Security Check

    Cursor is an AI code editor, not a host. That's what makes the security picture for Cursor-built apps different. Your app might be a Vite single-page app on Netlify, a Next.js app on Vercel, or an Express server on a VPS. The AI wrote code fast, you deployed it, and nobody in the loop checked what the production build actually exposes.

    The Pro Logica AI App Security Check is a free, passive scan of your live URL. It doesn't need access to your repo. It checks what any visitor or bot can see. Run a free Cursor app security check.

    The two gotchas in Cursor builds

    1. Environment variables inlined into the bundle

    Front-end frameworks copy certain environment variables into the JavaScript they ship. In Vite, it's anything that starts with VITE_. In Next.js, it's anything that starts with NEXT_PUBLIC_. Those values become plain strings in a file every visitor downloads.

    That's fine for a publishable key, an analytics ID or a Supabase anon key. It's a serious problem for a Stripe secret key, an OpenAI key or a database URL. AI assistants sometimes add a prefix just to "make the error go away" when a component can't read a variable. The build succeeds and the secret goes public.

    We read your homepage and up to eight of your own JS files and look for live key patterns: sk_live_ and rk_live_, AKIA… AWS keys, OpenAI and Anthropic keys, GitHub and Slack tokens, SendGrid keys, private key blocks, and Supabase JWTs whose role is service_role. Matches are masked in the report. We never store a full secret.

    Fix: rotate the key at the provider first, because it's already public. Then rename the variable without the public prefix, move the call into a server route or edge function, and have the browser call your route. Details in Exposed API key in frontend.

    2. Source maps shipped to production

    A source map links your minified bundle back to your original files, with comments and readable names. Vite's build.sourcemap defaults to false, and Next.js's productionBrowserSourceMaps defaults to false. Generated configs and error-monitoring setups often switch them on, though. When the .map files are public, anyone can rebuild your source. When you confirm ownership, we check whether .js.map files are reachable.

    Fix: set Vite's build.sourcemap to false, or to 'hidden' if you upload maps to an error tracker and then delete them from the deploy. In Next.js, remove productionBrowserSourceMaps: true. Full guide: Source maps exposed in production.

    Headers and the rest of the checklist

    Because Cursor apps run on many hosts, headers go wherever your host reads them:

    • Netlify: public/_headers or [[headers]] in netlify.toml
    • Vercel: the headers array in vercel.json, or headers() in next.config.js
    • Express: helmet() middleware
    • Nginx: add_header lines in the server block

    In our passive check of 18 public showcase apps built with Lovable or Bolt, 18 of 18 had no Content-Security-Policy, 15 of 18 had no sitemap we could find, and the average score was 76 out of 100. We didn't sample Cursor apps. The gap comes from the same place, though: nothing sets these headers unless someone asks. See the missing security headers checklist.

    We also check:

    • HTTPS and certificate expiry
    • CORS: Access-Control-Allow-Origin: *, which is worst when it's paired with credentials
    • Public /.env and /.git, a classic when a server serves the repo root. More in Exposed .env file.
    • Supabase or Firebase access for anonymous visitors (count-only and shallow tests, no data downloaded)
    • Google basics: noindex, title, meta description and sitemap

    Make Cursor help you stay fixed

    Cursor supports Project Rules, .mdc files in .cursor/rules that are added to Agent's context. A short rule that's always applied stops the same mistakes from coming back:

    ---
alwaysApply: true
---
- Never put secrets in variables prefixed VITE_ or NEXT_PUBLIC_.
- Third-party API calls that need a secret go in a server route.
- Never commit .env files; keep .env in .gitignore.
- Production builds must not publish source maps.
- Keep security headers (CSP, HSTS, nosniff, Referrer-Policy, frame-ancestors) in the host config.

    Rules guide the AI. They don't enforce anything, so keep a CI check that fails the build when sk_live_, AKIA or a service_role JWT appears in src/ or public/, and rescan after each release.

    What the full report adds

    The free result shows your score, findings by severity, and your top finding. When you unlock the full report, each finding gets masked evidence, a plain-English fix, and a copy-paste prompt written for Cursor's Agent. The prompt tells it which files to search, what to change, and how to verify the change, so you review a diff instead of guessing.

    Related

    FAQ

    Is Cursor itself insecure?

    This page isn't about the editor. It's about the apps people ship with it. AI-written code can be correct and still deploy with a public key, open source maps or missing headers. That's what we check.

    Do you need my GitHub repo?

    No. The scan only looks at your public URL. The fix prompts are written so Cursor can make the change in your repo.

    Which hosts do you support?

    Any public HTTPS site. The fix steps cover Netlify, Vercel, Express and Nginx, and the prompts tell Cursor to detect your host config.

    Will the scan trigger my WAF or rate limits?

    It's light: GET and HEAD requests only, about 40 at most, paced out, with a User-Agent that names Pro Logica and a contact address.

    How do I know a fix worked?

    Rescan. The finding drops off and your score goes up. For headers, curl -I https://your-domain shows them right away.

    Check what your Cursor build really ships. Run the free Cursor app security check.

    By Pro Logica