A security review prompt for vibe-coded apps, and what it cannot tell you

Asking the tool that wrote your application to check it is a reasonable first move. It is fast, it is free, and it does find real problems. It is also the single most over-trusted step in the whole vibe-coding workflow, mostly because the answer comes back fluent and confident regardless of how thorough it was.

So here is a prompt worth using, followed by the part most articles leave out.

The prompt

You are a hostile security reviewer. I am about to launch this application publicly. Do not reassure me and do not summarise what the code does. For each issue you find, give me the file, the line, what an attacker does with it, and the smallest change that fixes it. Work through these in order. 1) Database access: is row level security enabled on every table, and does each policy scope rows to their owner rather than merely requiring a logged-in user? 2) Secrets: is any key with elevated privileges reachable from client code or from a variable exposed to the browser? 3) Authorisation: for every endpoint that reads or changes a record, is ownership checked on the server, or only hidden in the interface? 4) Input handling: which state-changing endpoints accept unvalidated input, and where does user input reach a query, a file path, or rendered HTML? 5) Dependencies: which packages have known critical vulnerabilities? Finally, list what you could not check and what you had to assume. If you found nothing serious, say plainly which parts of the system you were unable to see.

Two details make this better than the usual request to check my app for security issues. It forbids reassurance, which is the failure mode of a model reviewing work it produced. And it ends by asking what the model could not see, which is where the honest answer usually lives.

What this genuinely catches

Used well, a prompt like this reliably surfaces the errors that account for most incidents in small applications: a table without row level security, a policy that only checks authentication, a privileged key in client code, an endpoint that trusts an identifier from the request, an obviously outdated dependency. These are real findings and fixing them meaningfully reduces your risk.

The four things it structurally cannot do

It only sees what is in the context window

The model reviews the files it was given. Your deployed configuration, your environment variables, the edge function someone added last month and the table created directly in the dashboard are all outside that. A clean report on a partial view is not a clean report.

It cannot test the running system

Reading code tells you what should happen. Whether your production database actually refuses an unauthorised read is a question about a running system, and it can only be answered by asking that system. Configuration drifts, and the gap between the code and the deployment is exactly where incidents live.

It is grading its own work

When the reviewer is the author, the review inherits the author's blind spots. A pattern the model considers idiomatic is unlikely to be flagged by the same model, however hostile you instruct it to be.

It produces no evidence

This is the one that matters commercially. A chat transcript is not something you can send to an investor, a procurement team, or an accelerator. It is not dated, not independent, not mapped to any standard, and not verifiable by the person reading it. It changes what you know. It changes nothing about what you can prove.

A sensible order of operations

1. Run the prompt and fix what it finds. Free, fast, and it removes the obvious problems.
2. Verify the two findings that matter most by hand: try to read another user's row with only your public key, and search your deployed bundle for a privileged key.
3. When someone else needs to trust the answer, get an independent validation that tests the running system and produces evidence with a date on it.

Most people should do the first two today. The third only becomes worth paying for at the moment your own word stops being enough, which is usually a raise, a contract, or a programme reporting on its cohort.