Security checks before you launch an app built with Cursor

The common holes in agent-built apps are secrets in client code, open database rules, routes that do not check who is asking, and no rate limits. Six checks you can run in an afternoon, each with a prompt for Cursor's agent.

Short answer: before you launch an app built with Cursor, check six things. No secret reaches the browser or git. Every database table with user data has access rules, and you have tested them with two accounts. Every API route checks who is asking. Login, signup and forms have rate limits. Input is validated on the server. Security headers and HTTPS are on. Give Cursor's agent one check at a time with the prompts below, and read its answer before you let it change code.

1. Secrets

Prompt: "Search the repository, git history and the production build output for API keys, tokens, passwords and service role keys. List each one with the file and whether it reaches the client. Do not print the values."

Secrets belong in server-side environment variables.
In frameworks that expose variables with a public prefix, such as NEXT_PUBLIC_ or VITE_, never give a secret that prefix.
Rotate any key that was ever committed, even if you deleted it later.

2. Database access rules

If you use Supabase, row level security decides which rows each user can see. Enabling it with no policies blocks everything; having it off with the public key in the browser can expose everything.

Prompt: "List every table, whether row level security is on, and its policies in plain words. Flag tables with user data and no policy."

Then test: sign in as user A, copy a record ID, sign in as user B and try to load it.

3. Route checks

Prompt: "For every API route and server action, show how it checks that the signed-in user may perform this action on this record. List routes with no check, and routes that trust an ID from the request."

4. Rate limits

Prompt: "Which endpoints can be called repeatedly without limit? Propose rate limits for login, signup, password reset, contact forms and any endpoint that sends email or costs money."

5. Server-side validation

Prompt: "List every endpoint that accepts input and whether it validates it on the server. Add schema validation where it is missing."

6. Headers and HTTPS

Check the live site redirects HTTP to HTTPS and sends basic security headers. Ask Cursor to add a content security policy carefully: a strict one can break scripts, so test the live site after.

Make it stick with project rules

Cursor's docs say project rules live in .cursor/rules, are version controlled, and can apply always or to matching files. Add a rule such as "never put secrets in client code; every route checks ownership". Our guide to Cursor rules for SEO and forms shows the format.

Where Persqo helps

Persqo is not a security scanner. It tests the app the way a visitor does, which catches a different set of problems:

Paste the Persqo prompt into Cursor's agent chat and your app gets a Persqo admin page at /admin/persqo. Your key goes in a server-only environment variable.
An AI visitor tests the live app on desktop and mobile, with screenshots and a replay, and checks basics such as HTTPS and security headers. Every finding comes with a fix prompt for Cursor.
One click: on a Next.js or Vite app, the Persqo fix runtime the prompt adds applies the home page title and description, business and FAQ schema and llms.txt, each with Undo. Next.js shows them within a minute, Vite at your next build.
Connect your repository and Persqo opens a pull request for file fixes such as llms.txt and robots.txt. You merge it; Persqo never merges.

Sources

The vibe coding master checklist, Supabase blog, checked November 6, 2026
Row Level Security, Supabase docs, checked November 6, 2026
Project rules, Cursor docs, checked November 6, 2026
Env variables and modes, Vite docs, checked November 6, 2026

Last updated: November 6, 2026.

Questions people ask

Is code written by Cursor insecure?

Not by default, but an agent writes what you ask for, quickly, and security checks are easy to skip when nobody asks for them. Review secrets, data access and rate limits yourself before real users arrive.

How do I check Supabase row level security?

Make sure RLS is enabled on every table with user data and that each has policies. Then sign in as two test users and try to read the other user's rows. Supabase's checklist says to enable RLS and test user data isolation.

Do I need a penetration test?

For most small launches, the checks here cover the common holes. If you handle health, financial or other regulated data, or sell to companies with security reviews, budget for a professional test.