The vibe coding security checklist

Here’s the uncomfortable truth about vibe coding. The AI is trying to make your app work, and “works” and “is safe” are different goals. A login screen that lets the right people in is easy. A login screen that keeps the wrong people out, in every possible case, is the hard part, and it doesn’t show up in the demo.

In 2025 security researchers found large numbers of apps built with popular AI builders exposing their users’ data, mostly because the database’s access rules had never been switched on. Nobody noticed, because everything looked fine from the front.

This checklist is the stuff that doesn’t show up in the demo.

Data and access

1. Every table has access rules switched on. If your app uses a database like Supabase, every table needs rules saying who can read and change each row. “The app only shows people their own data” is not enough. The rules have to live in the database itself, because anyone can talk to your database directly, without going through your app.

2. You’ve tested as two different users. Sign up twice with two email addresses. As user A, try to see, change or delete user B’s things. Try it by changing numbers in the address bar, too. If anything gets through, stop and fix it.

3. Admin pages check who you are on the server. Hiding the admin button isn’t security. If someone types the admin page’s address directly, they should be turned away.

4. Users can’t make themselves important. Check that nobody can edit their own role, credit balance, subscription level or “verified” badge, even by sending a hand-crafted request.

Secrets

5. No secret keys in the browser. Anything your app sends to the browser can be read by anyone. Keys with names starting NEXT_PUBLIC_ or VITE_ are public by design. Only keys meant to be public belong there. Payment keys, admin keys and AI provider keys must stay on the server.

6. No secrets in your code history. If a key was ever committed to your repo, even once and deleted later, assume it’s been seen. Change it.

7. Your AI spending is capped. If your app calls an AI model, set a spending limit with the provider. A leaked key, or a bored stranger with a script, can run up a frightening bill overnight.

Logins and input

8. You didn’t build your own login system. Use your platform’s built-in sign-in (Supabase Auth, Clerk and similar). Home-made password handling is where serious leaks come from.

9. The server checks everything. Anything checked only in the browser (prices, permissions, form limits) can be bypassed. Ask the AI to show you where each important rule is enforced on the server.

10. There are limits on how often things can happen. Sign-ups, logins, messages and anything that costs you money should have rate limits, so one person can’t do them ten thousand times a minute.

11. File uploads are restricted. Limit the size and type of files people can upload, and never let uploaded files run as code.

Money

12. Payment confirmations are verified. If you take payments, never trust the browser’s word that a payment happened. Confirm it on the server, from the payment provider or the blockchain directly.

13. Prices come from the server. If the price is in the browser, someone will change it to one cent and see what happens.

The boring bits that bite

14. The packages are real. AI tools sometimes suggest software packages that don’t exist, and scammers register those names with malicious code inside. It even has a name: slopsquatting. Check unfamiliar packages before installing them, and run your package manager’s audit command.

15. Errors don’t spill secrets. Error messages shown to users should be friendly and vague. Detailed errors, with database names, file paths or keys, belong in your private logs.

Make the AI check its own work (but don’t trust it alone)

AI tools are surprisingly good at finding security problems when you ask them directly, and surprisingly bad at avoiding them when you don’t.

Act as a security reviewer who is trying to break this app. Don’t change any code yet. Go through the project and list every place where:

• one user could see or change another user’s data
• a secret key is exposed to the browser or committed to the code
• something important is only checked in the browser, not on the server
• someone could do something unlimited times For each problem, tell me the file, how serious it is, and how you’d fix it.

Then fix the issues one at a time, testing as you go. And for anything that handles money or personal data, get a human who can read code to look over it too. An AI marking its own homework will miss the same things it got wrong in the first place.

Before you launch, the two-minute version

• Signed in as user A, can I touch user B’s stuff? No.
• Can I see any secret keys in the browser’s developer tools? No.
• Can I open admin pages without being an admin? No.
• Is there a spending cap on every paid service? Yes.
• Has someone other than me, or my AI, looked at it? Yes.