A 12-point security checklist for vibe-coded apps (with prompts you can paste)

John Banker — Wed, 21 Oct 2026 13:13:13 +0000

I'm a dad in north Georgia, building apps with AI coding tools and learning as I go. The scariest thing I've learned is that an app can work perfectly and still let anybody read everybody's data.

Most security problems in AI-built apps are the same handful: tables anyone can read, secret keys in the front end, routes that don't check who's asking, and prices the browser can change. Here's the checklist I run before I publish anything. Each check has a prompt you can paste into Lovable, Bolt, Base44, Cursor or Claude Code to check it for you.

This is a beginner checklist, not a professional audit. If your app takes payments or stores sensitive data, pay a human to look at it.

Run the built-in scan first. Lovable runs a quick security scan on publish and offers a deeper scan, and Base44 has a security scan too. Both vendors' docs say the scans don't replace reviewing your own app.

The one-shot review prompt

Before I publish, do a security review of this app. Don't change anything yet.
Check: row-level security / data permissions on every table, secret keys in front-end code, storage bucket access, server-side user checks on every route, where prices and "paid" status are set, rate limits on anything that sends email or calls a paid API, and what error messages show.
List each problem as Critical, Warning or Info, with a one-sentence fix. Then wait for me to pick what to fix first.

The 12 checks

1. Every table has row-level security. With Supabase (and Lovable Cloud, which is built on it), the key in your front end is public. RLS is what stops one user from reading everyone's rows. In Base44, data permissions do the same job.
List every table and whether row-level security is on, with its policies in plain English. Flag any table where a user could read or change another user's rows.

2. No secret keys in front-end code. Anything with a NEXT_PUBLIC_, VITE_ or EXPO_PUBLIC_ prefix ships to every visitor's browser. Service-role keys, Stripe secret keys and AI API keys must stay on the server.
Search the front-end code and environment variables for secret keys (service role, Stripe secret, OpenAI or other API keys). Tell me each one you find and where it should move.

3. .env is in .gitignore, and leaked keys get replaced. If a key was ever committed, deleting the file isn't enough. It's still in git history, so rotate the key.
Check that .env is listed in .gitignore and search the git history for committed keys. Don't rewrite history; just tell me which keys to rotate.

4. The server checks who the user is on every request. Hiding a button isn't security. Never trust a user id sent from the browser.
For every API route or edge function, tell me whether it checks the logged-in user on the server and whether it trusts any id sent from the browser.

5. Prices come from the server, and payment is confirmed by webhook. If the browser sends the price, someone will send $0. If "paid" gets set when a user opens /success, anyone can open that URL.
Show me where the checkout price is set and where a user gets marked as paid. Both must happen on the server, and paid status must come from the payment provider's webhook.

6. File storage is private. Public buckets are easy to create by accident.
List every storage bucket, whether it's public or private, and who can read and upload files in each.

7. Login is solid. Use the platform's built-in auth, and turn on email confirmation and leaked-password protection where they exist.
Review sign-up, log-in and password reset. Is email confirmation on? Is leaked-password protection on? Can a logged-out user reach any private page?

8. Anything that costs you money is rate-limited. Endpoints that send email or SMS, or call a paid AI API, can be hammered by a bot.
List every endpoint that sends email/SMS or calls a paid API, and whether it requires login and has a rate limit.

9. User input is checked before it's used. Validate it (for example with zod) before it reaches a query, file path, email or AI prompt.
Find every place user input reaches a database query, file path, email or AI prompt, and tell me whether it's validated first.

10. Dependencies have no known holes.
Run npm audit (or the platform's dependency check) and summarize anything high or critical, with the smallest safe upgrade for each.

11. Errors don't spill secrets. Show users a friendly message and log the details privately.
Check what a user sees when something fails. Make sure no stack traces, SQL errors or keys are shown on screen or returned by the API.

12. You can undo. Version history in your builder, commits in git, and a database backup.
Tell me how I'd roll back the app and the database to yesterday's version if something went wrong after launch.

Stop it happening in the first place

Put these lines in your rules file (AGENTS.md, CLAUDE.md, a Cursor rule, or Lovable/Bolt Project Knowledge) so the AI builds it safely the first time:

## Security rules
- Every new table gets row-level security with explicit policies in the same change. Users only see their own rows unless I say otherwise.
- Secret keys live only in server-side environment variables or the platform's Secrets. Never in front-end code, never with a NEXT_PUBLIC_, VITE_ or EXPO_PUBLIC_ prefix, never in git.
- Every API route or function checks the logged-in user on the server. Never trust a user id from the browser.
- Prices are set on the server. A user is marked as paid only by the payment provider's webhook.
- Storage buckets are private unless I ask for public.
- Validate all user input before it reaches a query, file path, email or AI prompt.
- Ask before changing auth, payments, permissions or the database structure.

What did I miss? If you've been bitten by something that isn't on this list, tell me in the comments and I'll add it.

I wrote this up on my own site, VibeKits, where it has the sources (Lovable, Base44, Supabase, Next.js and Stripe docs) and stack-specific versions: https://getvibekits.com/rules/vibe-coding-security-checklist/ . It's free, with no signup. I also sell a few build kits there, but nothing above needs them.

DEV Community: John Banker

A 12-point security checklist for vibe-coded apps (with prompts you can paste)

The one-shot review prompt

The 12 checks

Stop it happening in the first place