How to secure an app built with Cursor

Cursor gives you real code in your own repository, which means you are responsible for the parts a hosted builder would hide. These are the five places apps built with it most often go wrong.

1. Keep .env out of git

Check that .env and .env.local are in .gitignore, and that they were never committed:

git log --all --oneline -- .env .env.local

If that prints anything, the secrets are in your history even if the file is gone. Rotate those keys. Greenlight Scan’s Launch Audit scans your repo files for this (full git history where available).

2. Watch the public prefixes

In Next.js, variables starting with NEXT_PUBLIC_ are sent to the browser. In Vite, it is VITE_. Never put a secret key behind those names.

Search the project for environment variables starting with NEXT_PUBLIC_ or VITE_ and tell me which ones contain secrets (secret API keys, service role keys, private tokens). Rename them without the prefix and move the code that uses them to server-only code.

3. Protect every API route

AI-generated routes often fetch data for whoever asks. Each route that returns or changes user data must check the session on the server.

Review every file in app/api (or pages/api). For each route that returns or changes user data, add a server-side check that the caller is signed in and owns the data, returning 401 or 403 otherwise. Do not trust user ids sent in the request body.

4. Lock down CORS and headers

Do not set Access-Control-Allow-Origin: * on routes that use cookies or tokens. Add security headers in next.config (HSTS, X-Frame-Options, a Content-Security-Policy).

5. If you use Supabase

Turn on Row Level Security for each table and never use the service_role key in client code. See our Supabase RLS post.

Before you deploy

Run the free scan on your preview or production URL to see your score and problem count. The Full Scan then gives each finding a prompt written for Cursor, ready to paste into the chat.