Is your Cursor-built app leaking?

What a Cursor app ships with

• Whatever you asked for: Vite, Next.js, Express, Django, or all of them. The scanner reads the deployed result, not the editor.
• A GitHub repository, usually from the first hour, often before .gitignore existed.
• Keys that started as constants "for now" and are still there.
• Hosting on Vercel, Netlify, Railway, Fly, or a VPS, each with its own place for headers and redirects.

The five things that go wrong

1. A .env in the first commit. The most common Cursor-era leak: the repo got pushed before .gitignore. Deleting the file later does not remove it from history; only rotating the keys makes it harmless.
2. A key hardcoded in client code. OPENAI_API_KEY = "sk-..." in a React component to get past an error, then forgotten. The scan reads the bundle, chunks included, for the known key formats and reports them redacted.
3. Source maps in production. Great in development, a gift to anyone reverse-engineering the app in production.
4. CORS set to * with credentials. Browsers refuse that exact combination, but the intent behind it, allow everyone, tends to become an echoed Origin in the next edit, which browsers do accept.
5. Missing headers on a self-hosted server. Nginx or Express behind Cloudflare sends nothing unless told. The fixes are one line per header.

How to fix them

Stop tracking .env and rotate what was in it

echo .env >> .gitignore
git rm --cached .env
git commit -m "stop tracking .env"
git push
# then rotate every key that was in the file; the history still has the old values

Turn off production source maps

vite.config.ts:      build: { sourcemap: false }
next.config.js:      productionBrowserSourceMaps: false
.env.production:     GENERATE_SOURCEMAP=false   (Create React App)

Headers on Nginx

add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
server_tokens off;

Every finding in a scan comes with the exact lines for your host and framework, opened for the one it detected.

Questions people ask

Can it check the repository, not just the site?

Yes, after sign-in. Connect the GitHub repo and it reads the code through the Left Unlocked GitHub App: committed .env files (names only), leaked keys (redacted), a service-role key in client code, and Supabase migrations that create tables without RLS. It can then open a pull request for what a file can fix, on its own branch, for you to review.

I rotated the key. Do I still need to rewrite Git history?

Not for safety; the old key is dead. Rewrite only if the repository is public and you would rather not show the mistake.

How often should I re-scan?

After every deploy is ideal; weekly is what monitoring does for you, with an email only when something new is wrong.