Cursor app security checklist

These are ordinary failure modes in an app that was assembled quickly, including an app written with a coding agent. They are general guidance, not a list of Cursor product features.

A secret ends up in a client component or as a string in the bundle. A server key is given a NEXT_PUBLIC_ or VITE_ prefix so the preview can read it. Next.js inlines NEXT_PUBLIC_ into the browser bundle at build time. Vite exposes VITE_ names to client code. Sources: Next.js environment variables and Vite env variables.

A Supabase client is wired up with the anon key, which is normal, while the tables have no row level security policy. The browser cannot tell you that. The production build can also emit .js.map files that the host then serves, and the response can omit Content-Security-Policy, HSTS, a clickjacking control, X-Content-Type-Options, or Referrer-Policy.

The free Quick Check fetches the public HTML, same-origin JavaScript, security headers, cookie flags, and whether the URL stays on HTTPS. It also requests seven fixed paths: /.env, /.env.local, /.env.production, /.git/config, /.git/HEAD, /.aws/credentials, and /.npmrc. Source maps named by those scripts are included. Matched secrets are masked. The free page writes the fix for the single most serious finding.

It does not query tables. It does not test row level security. It does not log in, brute force, fuzz, or enumerate paths beyond that list. An anon Supabase key in the bundle is client configuration. A service_role key in the bundle is a finding. Neither one tells you whether policies exist.

The €19 Launch Report opens the rest of that same pass. It does not scan anything new. Monitor, €9 per month, repeats the same passive check each week and when a deploy hook fires. It will not notice a table with row level security off.

Publish the app, then run the free check on that URL. The editor preview is not the check.

Rotate anything the report shows. Remove it from client code and from NEXT_PUBLIC_ and VITE_ names. Read server secrets from the host environment in server code only.

Open the Supabase guides linked below and confirm grants and row level security in the database. Then remove public source maps and add the missing headers on the host that serves the site.

If you keep shipping, Monitor repeats the same passive check. It still does not query tables or test row level security.

If a .js.map file is public, turn off maps that ship to browsers, or keep stack traces without serving the files. In Vite set build.sourcemap to 'hidden' (or false to omit maps). In webpack set devtool to 'hidden-source-map'. In Next.js leave productionBrowserSourceMaps off, which is the default. Upload the maps to your error tracker in CI, then delete the .map files from the deploy output. A hidden map is still public if the file is deployed beside the script. Vite documents 'hidden' as a map file without the sourceMappingURL comment. Webpack documents hidden-source-map the same way. Next.js documents that production browser source maps stay off unless you opt in.

Missing headers are fixed on the host that serves the published URL. The check looks for Content-Security-Policy, Strict-Transport-Security on HTTPS, clickjacking protection (X-Frame-Options or CSP frame-ancestors), X-Content-Type-Options, and Referrer-Policy.

If the app uses Supabase, open the RLS check and the 30 October grant note. Confirm row level security and the GRANT yourself. Disabling RLS is not the fix for a missing grant. This scan does not query tables, so it cannot do that confirmation for you.