You didn't write the code, but you own the breach: a security check for vibe-coded apps

Here is the uncomfortable truth about vibe coding: you may not have written a single line of the code, but if your app leaks your users' data, the breach is yours. The tools that let non-engineers ship apps also quietly provision databases, authentication, and API keys — and they do not make sure any of it is secure. That's your job, and almost nobody tells you so until it's too late.

This is the plain-English security check every vibe coder should run before launch. No jargon, no code — just a series of things to look at and fix. It takes about fifteen minutes, and it is the difference between shipping safely and becoming the next cautionary tale. If you've built something with Lovable, Bolt, Replit, v0, or Cursor and real people are about to use it, start here.

Why AI-built apps are insecure by default

The pattern is consistent. AI writes for the happy path — the version where everything works and everyone behaves — because that's what you asked for. It puts secret keys where they're convenient, not where they're safe. It wires up a login without necessarily protecting the data behind it. And the tools provision a real database and real infrastructure automatically, without ever explaining that you now own the responsibility for locking it down.

The cruel part is that none of this shows up in the demo. Your app works. It looks finished. The security holes are invisible until someone — a curious user, a bot scanning the internet, an attacker — finds them. By then your database of emails is public and there's nothing to undo.

The builders who get burned aren't reckless. They just never knew a database was created, that it was public by default, and that closing it was on them.

The 15-minute security check

Run these five checks in order. For each, if you can't confirm it's safe, that's your next fix. You don't need to know how to code — you need to know what to look for and what to ask the AI to fix.

1. No secret keys in the frontend

Secret API keys — for your AI provider, your payment processor, your database's admin access — must live on the server, never in the code that ships to the browser. If a key is in the frontend, anyone can open their browser's developer tools, read it, and run up your bill or access your data. Ask your AI tool directly: "Are any secret or private API keys exposed in the frontend or client-side code? List every key and where it lives." Then have a second tool verify the answer.

2. Your database isn't open to the world

Most AI builders use a database (often Supabase) that is public by default until you turn on access rules — called Row Level Security, or RLS. Without them, anyone who finds your database address can read and write everything in it. This is the single most common vibe-coding breach. Ask: "Is Row Level Security enabled on every table? Which tables can be read or written by anyone?" If the answer is that any table holding user data is open, that's a launch-blocker.

3. Authentication actually protects private data

A login screen is not the same as protection. The real question is whether a logged-in user can reach data that isn't theirs — or whether someone can skip the login entirely by hitting the right address. Test it yourself: log in as one test user, note what you can see, then try to view another user's data by changing the URL or IDs. If it works, your auth is decorative.

4. Payments can't be bypassed

If you charge money, the check for whether someone has paid must happen on the server, tied to their actual account — not in the browser, where it can be edited away. A well-documented failure mode is an app where anyone can unlock the paid features by tweaking what the browser sends. Ask: "Is the paid/unpaid check enforced on the server and tied to the authenticated user, or can it be bypassed from the client?"

5. Nothing sensitive is logged or exposed in errors

Error messages and logs sometimes spill secrets — keys, tokens, other users' details. Trigger a few errors (wrong inputs, empty forms) and read what comes back. If an error message contains anything that looks like a key or private data, that needs to be hidden before launch.

What Reddit and Hacker News actually say

Search for vibe-coding security stories and the community verdict is blunt and consistent. It's worth hearing, because it's the part the tool marketing leaves out.

• "There's no way around learning the basics." The most-upvoted take on Hacker News threads about vibe-coding breaches is that no amount of AI removes the need to understand, at least a little, what a database and authentication are. You can offload the typing, not the responsibility.
• "You never see the warning." A recurring observation: because these tools provision infrastructure behind the scenes, builders never open the database dashboard where the security warnings live — so the alerts that would have saved them are never seen.
• "It's not the tool's fault, but it is the tool's design." Practitioners note the builders make insecure defaults easy and secure setup invisible. The fix is on you, but the trap is structural — which is exactly why a checklist like this exists.

If you find a problem

Don't panic, and don't ignore it. Fix one issue at a time, starting with anything that exposes user data or secret keys. Describe the exact problem to your AI tool and ask for the specific fix, then verify with a second tool. If the app already has real users and you find a serious leak, take it offline while you fix it — a temporarily-down app is far better than a permanently-breached one.

And if this feels over your head, that's a signal, not a failure. It may be the moment to bring in someone who can read the code — the natural graduation point covered in our guide to vibe coding. For the tools that make each of these checks easier, see the tools every vibe coder should know.

Common questions

Can I get hacked if I built my app with AI?

Yes — AI-built apps are hacked regularly, almost always through leaked keys, open databases, or bypassable authentication. The good news is these are the same handful of issues every time, so a fifteen-minute check catches the vast majority before anyone can exploit them.

Do I need to understand code to secure my app?

Not to run this check — it's about knowing what to look for and what to ask the AI to fix. But the community consensus is real: learning the basics of how databases and authentication work makes you dramatically safer, and it's worth doing as you build.

The takeaway: the tool built your app, but you own its safety. Run the five checks — keys, database access, real authentication, payment enforcement, error leaks — before anyone real touches it, and verify every answer with a second tool. Fifteen minutes now beats an irreversible breach later. More guides for building safely on the Kapyn Radar.