From Vibe Coding to Live Users

AI tools are optimised for speed. They get the app running. They don't think about what happens when someone tries to break it.

The login page works. The data loads. Everything looks fine. But underneath, the database might be completely open — no lock, no rules, wide open to anyone who knows where to look.

The problem isn't that you used AI to build. The problem is shipping without checking.

He wrote a script that ran the same test on 1,645 apps from Lovable's own showcase. 170 of them, around 10 percent, had the exact same problem.

The root cause: missing Row Level Security policies on the database. Without RLS, anyone with the public anon key — which sits in the frontend by design — could query the database directly and get whatever they asked for.

The apps looked fine. The login pages worked. Nothing on the surface told you anything was wrong.

Authentication is the most important security layer in your app. It is also where most vibe-coded apps get breached. AI will write auth that works in a demo. It won't handle what happens when someone tries the wrong password 50 times, or when a session doesn't expire, or when two accounts share an email. Those are the gaps attackers walk through.

The good news: you don't have to build it. Use a provider that has already solved this.

When you build with Supabase, your database has a key that lives inside your frontend code. That's normal — the key is meant to be public. What makes it safe is something called Row Level Security, or RLS.

RLS is the set of rules that says who can see what. Without it, that public key gives anyone access to every row of every table — not just their own data, but everyone's data.

The most common mistake: AI turns RLS on but writes a rule that says "any logged-in user can read everything." That sounds reasonable. It means every user can read every other user's data.

Your app connects to other services — an AI model, a payment processor, an email provider. Each uses a secret key. Anything in your frontend JavaScript is visible to anyone. Open a browser, hit inspect, and you can see it.

Moving secrets to your backend isn't enough on its own. If you hardcode them directly into your backend files, they can still end up committed to git. The correct home for every secret is a .env file — and that file should never be committed.

Security headers are instructions your server sends to the browser. They tell the browser what it's allowed to do — which scripts can run, whether the page can be embedded in another site, whether connections must use HTTPS.

They take minutes to add and they close off a whole category of attacks. Most vibe-coded apps ship with none of them configured.

When your frontend talks to your backend, that's fine. But without restrictions, anyone else's website can also send requests to your backend — and those requests might work.

CORS is how you tell your server which origins are allowed. The common mistake is setting it to allow everything. That means your backend accepts requests from anywhere on the internet.

Most vibe-coded apps validate input on the frontend — they check the email looks like an email, the name isn't empty. That's fine. But it's not security.

Anyone can bypass your frontend entirely. They can skip your form completely and send any data they want directly to your server. If your server accepts it without checking, it goes straight into your database.

Every piece of data from a user needs to be validated again on the server — the type, the length, the format. Not because you don't trust your users. Because you can't control what reaches your server.

Both are old attacks. They still work because AI-generated code often skips the protections that prevent them.

Four things help. Write a clear system prompt telling the AI what it can't do. Pass user input as labelled data rather than mixing it into instructions. Only give your AI access to the current user's data. Consider checking the AI's response before sending it back.

When your app is live and something goes wrong, you need to know about it. That means setting up error monitoring from day one.

One thing to watch: when errors get logged, they often capture more than they should. A stack trace can include a database URL. A failed request can log a user's email or a token. Check what your logs actually contain and strip anything sensitive — this is also a GDPR requirement.

If your app calls a paid API and you haven't set limits, you're exposed. Someone finds your endpoint, writes a loop, and your bill runs up thousands of dollars before you wake up. This has happened to real founders. Rate limiting and spend caps both need to be in place before you launch.

Cloudflare is worth setting up regardless — point your domain through it and you get rate limiting, bot protection, and HTTPS for free. It's one of the highest-leverage things you can do before launch.

This isn't about being a lawyer. It's about not being reckless. If your app collects any user data — emails, names, anything — you need a privacy policy. If any of your users are in Europe, GDPR applies to you regardless of where you are based. That means cookie consent, a way for users to request deletion, and clear terms around how you use their data.

A terms of service page protects you when things go wrong. And collect only what you actually need — every field you ask for is data you're responsible for.

Whatever tool you built with — Lovable, Cursor, Bolt, Replit, anything — you can connect your project to GitHub and bring it into Claude Code. Claude Code reads your entire codebase at once and can do a thorough security review in one session.