Cursor Security Checklist: 5-Minute Check Before You Ship

A Cursor security checklist should cover the app you deployed, not just the code in your editor. In five minutes you can search your public JavaScript for secret keys, confirm /.env and /.git aren't served, turn off public source maps and check your security headers. None of that happens automatically when Cursor writes the code.

By Gary, Greenlight My App · Updated Oct 30, 2026 · How we checked this: We read Cursor's ignore-files and agent security docs on Oct 30, 2026 and wrote the checks below from our own launch checklists. We have not run a hands-on test of Cursor for this post. Drafted with AI tools and reviewed by a person before publishing.

Cursor security is getting attention this week. The worry is simple: an AI editor wrote most of your app, you shipped it, and now you're not sure what's sitting in public. Here is a short check you can do yourself.

Why do Cursor-built apps leak secrets?

Most leaks come from ordinary shortcuts, not from Cursor itself. A key gets pasted into a component to make a demo work, an .env file lands in the build folder, or a framework variable prefix like NEXT_PUBLIC_ or VITE_ sends a server key to the browser. The AI does what it's asked, and a working demo looks the same whether the key is on the server or in the bundle.

Ignore files help, but Cursor is clear about their limits. Its ignore files docs (external) say (checked Oct 30, 2026): "The terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore." So treat .cursorignore as a way to reduce risk, not a lock. For more on how Cursor's agent handles commands, see Cursor's agent security docs (external).

The 5-minute Cursor security checklist

Do these against your live URL, in this order.

1. Search your public JavaScript for secret keys (2 minutes)

Open your site, then DevTools > Sources (or Network > JS). Search the loaded scripts for common secret prefixes:

A hit looks like const key = "sk-XXXX" in your bundle. Publishable keys (like Stripe pk_live_ or a Supabase publishable key) are meant to be public; secret ones aren't. See Stripe API keys and Supabase publishable key for the difference.

2. Check for exposed files (1 minute)

Visit these paths on your domain. Each should return a 404 or a block, not file contents:

• /.env
• /.git/config
• /main.js.map (or any .map file your scripts reference)

If .env ever made it into Git history, read .env file committed to Git. Public source maps can hand out your original code; see source maps in production.

3. Check your security headers (1 minute)

Run your URL through our security headers checker. Look for HTTPS with HSTS, a content security policy and X-Frame-Options. Missing headers aren't a leak, but they make some attacks easier.

4. Check your database rules (1 minute)

If your app uses Supabase or Firebase, confirm row level security or security rules are on for every table that holds user data. Our guides on what is Supabase RLS and Firebase security rules walk through it.

5. Reduce what Cursor can see next time

Add a .cursorignore in your project root, for example:

# .cursorignore (based on Cursor's docs)
**/.env
**/.env.*

This lowers the chance the agent reads those files, but per Cursor's docs above, it isn't a hard boundary. Keep production secrets in your host's environment settings instead of local files where you can.

What if I find a leaked key?

Revoke it in the provider's dashboard first, then create a new one, update your server, and redeploy. Rotating alone isn't enough: a committed key stays in git history, forks and clones even after you delete the commit, so revoke the old one. Then check the provider's usage logs and billing back to the day it went live. Our step-by-step guide is API key leaked? What to do in the next hour.

Can I automate this check?

Yes, partly. Run a free Greenlight My App scan of your live app. It's automated, read-only and educational, not a security audit: it checks HTTPS, common security headers, exposed .env or .git files, public source maps and common secret key patterns in the scripts your homepage loads. "Nothing found" isn't a guarantee that nothing is exposed, so still do the database check by hand.

FAQ

Is Cursor safe to use for building apps? Cursor is a code editor; whether your app is safe depends on what you ship. Keep secret keys on the server, review what the agent changes, and check your live site before launch.

Does .cursorignore protect my .env file? It reduces the risk but isn't a hard boundary. Cursor's docs say its Agent's terminal and MCP tools cannot block access to ignored files. Keep real secrets out of the repo where you can.

How do I know if my API key is exposed in my frontend? Open DevTools on your live site and search loaded scripts for prefixes like sk-, sk_live_, AIza or AQ. Any secret key you find there is public and should be revoked and replaced.

What should I do first if a key leaked? Revoke it in the provider's dashboard, then make a new one and redeploy. Rotating alone isn't enough: it stays in git history, forks and clones. Check the provider's usage logs and billing.

Built your app with Cursor? Spend five minutes on the checklist above, then run a free Greenlight My App scan before you share the link.