Vibe-Coded App Security Checklist (2026)
The 12 security checks to run on your Lovable, Replit, Bolt or Claude Code app before you invite real users.
NOV 5, 2026 • TEAM NFN
You built the thing. It took a weekend, maybe two. Lovable, Replit, Bolt or Claude Code did most of the typing, the demo works, and a few people have already asked for access.
This is the moment to slow down for one afternoon. Not because AI-built apps are bad, but because the tools are tuned to make things work, not to make things safe. The gaps they leave are predictable, and most of them can be fixed before anyone outside your team logs in.
We’ve written before about taking a vibe-coded app to production. This post zooms in on the part founders ask us about most: security. Here’s the checklist we run when a founder hands us an AI-built app.
Is vibe coding safe?
It can be. The code an AI writes isn’t automatically worse than code a junior developer writes. The problem is that nobody reads it. When you accept every change because the screen looks right, you also accept whatever the model did with your keys, your database and your users’ data.
Public research this year keeps finding the same pattern: scans of thousands of public vibe-coded apps turning up exposed API keys, and databases that hand out records to anyone who loads the page. None of it is exotic hacking. It’s open doors. Good teams build with security by design; vibe-coded apps usually need it added afterwards.
So the honest answer: vibe coding is safe enough for a prototype with fake data. Before real users, real data or real money, run the checks below.
The vibe-coded app security checklist
1. Secrets and keys
Check 1: No secret keys in the frontend. Open your deployed site, view the page source and the network tab, and search for “key”, “secret”, “sk_” and “service_role”. Anything that grants write access or costs money (Stripe secret keys, OpenAI keys, your database service key) must live only on the server.
Check 2: No secrets in git history. Deleting a key from the code doesn’t remove it from old commits. Run a secret scanner over the whole repo history. If a key was ever committed, rotate it. Don’t debate it, rotate it.
Check 3: Separate keys for dev and production. One key everywhere means one leak breaks everything. Give production its own keys and limit who can see them.
2. Database and data access
Check 4: Row-level security is on, on every table. If you’re on Supabase or a similar backend, this is the big one. Without row-level security (RLS) policies, the public “anon” key your frontend uses can often read or edit every row. Turn RLS on for every table, then write policies so users can only touch their own data.
Check 5: Test as another user. Create two test accounts. Log in as User A and try to load User B’s records by changing an ID in the URL or the API call. If it works, you have the most common bug in AI-built apps. Fix it on the server, not by hiding a button.
Check 6: Collect less. Every field you store is a field you can leak. If you don’t need date of birth, phone number or full addresses for v1, don’t save them.
3. Authentication and sessions
Check 7: Use a proven auth provider. Don’t let the AI invent its own login system. Use Supabase Auth, Clerk, Auth0, Firebase Auth or similar, and turn on email verification.
Check 8: Protect every route on the server. A page that redirects logged-out users in the browser is not protected. The API behind it must check who’s asking, every time. Ask your AI tool to list every endpoint and confirm what each one checks; then verify a few yourself.
4. Payments, AI spend and abuse
Check 9: Never trust the browser on money. Prices, plan limits and “is this user paid?” must be decided on the server, ideally confirmed by your payment provider’s webhooks. If the frontend sends the price, someone will change it.
Check 10: Put a ceiling on your AI bill. An exposed endpoint that calls an LLM is a credit card with no limit. Add rate limits per user and per IP, set hard spending caps with your model provider, and alert yourself when usage spikes overnight.
5. Testing, logging and recovery
Check 11: Test the unhappy paths. AI tools test the path where everything goes right. Try empty forms, huge uploads, weird characters and expired sessions. This is where proper QA and test automation earns its keep: a small suite of automated tests stops the next AI-generated change from quietly undoing a fix.
Check 12: Know when something breaks, and be able to undo it. Turn on error tracking, keep logs of sign-ins and admin actions, and make sure your database has automatic backups you’ve actually restored once. Update dependencies with known vulnerabilities before launch.
How to run this checklist in one afternoon
You don’t need a security team to do a first pass. Block three or four hours and go in this order:
Hour 1: Secrets. Scan the frontend bundle and git history, rotate anything exposed, move keys server-side.
Hour 2: Data. Turn on RLS, write policies, and do the two-account test on every important screen.
Hour 3: Money and abuse. Check payment logic, add rate limits and spending caps.
Hour 4: Safety net. Error tracking, backups, a handful of tests for login and payments.
A useful trick: ask your AI tool to attack its own work. Prompt it to find hardcoded secrets, endpoints with no auth check, and places where one user could read another’s data. Treat its answers as leads to verify, not as a clean bill of health.
When to bring in a team
Run the checklist yourself first. Bring in experienced engineers when any of these are true:
You handle payments, health, financial or children’s data.
You’re about to onboard paying customers or a business client with a security questionnaire.
The two-account test failed and you’re not sure how deep the problem goes.
Every fix the AI makes seems to break something else.
At that point the question is usually fix or rebuild. Often it’s neither: you keep the screens and flows that users like, and harden the backend, auth and data layer underneath.
FAQ
Are vibe-coded apps secure?
Not by default. They can be made secure, but the AI won’t do it unless you ask for it and check the result. The most common issues are exposed keys, missing database rules and routes that aren’t protected on the server.
How do I secure a vibe-coded website?
Move every secret to the server, turn on row-level security, use a proven auth provider, check permissions on every API route, rate-limit expensive endpoints and add backups and error tracking. The 12-point checklist above covers each step.
Is Supabase safe for vibe-coded apps?
Yes, if row-level security is enabled with proper policies and the service role key never reaches the browser. Most Supabase leaks come from configuration, not from Supabase itself.
Can AI find security issues in my code?
It can help. Asking your coding tool for a security review, or running a scanner, catches obvious issues like hardcoded keys. It misses logic problems, such as one user reading another’s data, so test those by hand.
Ship fast, then make it hold
Vibe coding got you to a working product faster than anyone could a few years ago. Keep that speed. Just don’t let your first thousand users be your security testers.
If you’d like a senior team to audit and harden your AI-built app, we do it at a fixed price, no ‘it depends’. Talk to NFN Labs and we’ll tell you what to fix, what to keep and what it will take.
