Home › Rules › Vibe coding security checklist
Vibe coding security checklist: 12 checks before you launch
Short answer: 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. Go through the 12 checks below. Each one has a prompt you can paste into Lovable, Bolt, Base44, Cursor or Claude Code to check it for you.
Run the built-in scan first. Lovable runs a quick security scan every time you publish and offers a deeper scan from the Security view. Base44 has a security scan with recommended fixes. They catch a lot, but both vendors' docs say the scans don't replace reviewing your own app.
The one-shot review prompt
Short on time? Paste this, then work through what it finds.
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 checklist
1. Every database table has row-level security
With Supabase (and Lovable Cloud, which is built on it), the key in your front end is public. Row-level security (RLS) is what stops one user reading everyone's rows. In Base44 the same job is done by data permissions.
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 is bundled into the code every visitor downloads. 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
Bots constantly scan public repos for leaked keys. If a key was ever committed, deleting the file isn't enough: it's still in git history, so rotate (replace) 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. Every route or function that reads or changes data must check the logged-in user on the server and never trust a user id sent by 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; payment is confirmed by webhook
If the browser sends the price, someone will send $0. If "paid" is 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. Users should only reach files they uploaded unless you mean otherwise.
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. Turn on email confirmation and leaked-password protection where available (Lovable's publish scan checks the latter).
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 limited
Endpoints that send email, text messages or call a paid AI API can be hammered by a bot and run up your bill.
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
Untrusted text can end up in a database query, a file path, an email or an AI prompt. Validate it first (for example with zod) and never build SQL from raw text.
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
Old packages with known vulnerabilities are a free win for attackers. npm audit lists them; Lovable's quick scan checks them on publish.
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
Stack traces and raw database errors can show table names, file paths or keys. 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
Before launch, make sure you can get back to a working version: version history or bookmarks 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 the problems before they start
Add these lines to your rules file (AGENTS.md, CLAUDE.md, a Cursor .mdc 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.
Stack-specific versions with the reasons behind each rule: Supabase app, Lovable + Supabase, online store with Stripe, Next.js SaaS MVP.
When to get a human to look
If your app takes payments, stores health, financial or other sensitive data, or has more than a handful of real users, pay for a professional review. Lovable's own docs recommend one for apps handling sensitive data.
Best value
Get all 5 kits for $25 with 30% off: code WELCOME30 at checkout (through Nov 30, 2026)
The MVP Spec-to-Build Pack in our bundle builds this in from the start: a one-page spec, a 7-prompt build sequence in the right order, and a "did I leak user data?" checklist. The Codebase Fixer Agent helps you fix what this checklist finds, one safe change at a time.
Get all 5 kits for $25 → See what's in each kit
$25 instead of $39 for the five kits bought separately; WELCOME30 takes 30% off that at checkout ($17.50). Instant download from Gumroad. 7-day refund, no questions asked.
Related
- Lovable prompts that work (including the safe payments prompt)
- Base44 vs Lovable for beginners
- CLAUDE.md examples and best practices
- Cursor rules examples (with a secrets rule and a pre-launch checklist rule)
- Rules for cleaning up an existing codebase
Sources
- Lovable docs: Security overview (Quick scan, Deep scan)
- Lovable docs: Security best practices for Lovable apps
- Base44 docs: Running a security scan
- Base44 docs: Managing data permissions
- Supabase docs: Row Level Security
- Next.js docs: Environment variables (NEXT_PUBLIC_)
- Stripe docs: Webhooks
- OWASP Top 10
Checked Oct 19, 2026. These tools change often; if something here no longer matches, tell us at [email protected].