Can your users see other people's data? Check your prototype yourself

For vibe coders and founders whose prototype from Lovable, Bolt, Cursor or Claude Code already has its first users. Open the repository in the tool, paste the prompt and let the agent work. It takes about 10 minutes.

AI writes all of our code today and a senior is accountable for the result. These six areas are the first thing we check on every prototype we take over.

1. The prompt

The prompt forbids the agent to change anything or print secrets in full.

You are a security reviewer. Go through this repository and do not change anything in it. Do not run commands that write anything, deploy, or connect to production. When you find a secret (key, password, token), do not print it in full: give only the file, the line and the first 4 characters.

Check these 6 areas. For each one, write STATUS (OK / PROBLEM / DON'T KNOW), EVIDENCE (file and line, or what is missing) and WHAT TO DO (one sentence).

1. Data access (RLS): if the app uses Supabase, Firebase or a similar database called directly from the browser, does every table have Row Level Security or security rules enabled that let a user reach only their own rows? List tables without rules and rules that let everyone in.
2. Keys in code: are there keys, passwords or tokens in the repository or in the git history? Is .env in .gitignore? Is there a key in code that runs in the browser that does not belong there (service role key, secret API key, payment key)?
3. Login and permissions: does the server check, on every API route, who is logged in and whether they may access this data? List routes that return or change data without a check. Is the role (for example admin) checked on the server, or only by hiding a button in the UI?
4. Where it runs: are hosting, database and domain on a company account, or on one person's personal account? Look for traces in the configuration (project names, emails, URLs). If you cannot tell from the code, write DON'T KNOW and what I should ask.
5. Backups: is a regular database backup set up, and is it written down somewhere how a backup is restored?
6. Monitoring: will we learn about an error in production before a user does? Look for error tracking, logs and alerts.

At the end, give a table: area, status, severity (CRITICAL / HIGH / MEDIUM) and the most important step. CRITICAL is anything that lets a stranger reach other people's data or secrets. Sort the table from the biggest risk and write the number of findings per severity under it. Do not make anything up: whatever you cannot see in the code, mark DON'T KNOW.

2. How to read the answer

• Fix a PROBLEM in areas 1 to 3 before more users arrive. That is where a stranger most often reaches other people's data.
• DON'T KNOW is not OK. It means the answer is not in the code. Ask whoever has access to the hosting and the database.
• Verify at least one finding yourself. Open the file and line the agent named. If nothing is there, the agent is making things up, so treat the other findings with care.
• Replace any key that has ever been in the repository. Deleting it from the code is not enough, it stays in the history.
• OK in all six does not mean the prototype is secure. The prompt finds some of the problems, not all of them. It only means the basics are in place.
• Harden or rewrite? Once you know what to fix, the prototype test tells you whether fixes are enough.

3. What the check found

Tick the areas where the agent wrote PROBLEM or DON'T KNOW.