The security risks of vibe coding — and how to close them

Why vibe coding produces these holes

An AI builder optimizes for the demo: you asked for a feature, it produced a feature that works when you use it the intended way. Security is the opposite discipline — it's about the unintended ways. A skeptical human developer instinctively asks "what if the request comes without a login? what if the ID belongs to someone else? what if this field contains a script?" The model, prompted for a result, rarely asks those questions unless you make it. That's not a flaw you can prompt away entirely; it's a gap you close by checking. The good news: the gaps are predictable, so the checks are too.

Below are the seven risks in rough order of how often they cause real damage. Each links to a deeper guide where relevant.

1. Broken access control (the data-leak risk)

The single most common serious hole. Your app hides the "edit" button unless you own a record — but the API behind it never checks ownership, so any logged-in user can edit anyone's data by calling it directly. This is IDOR, OWASP's number-one category. It happens because the AI secures the interface, not the data. Check it: make two accounts, note a record ID as account A, and try to read or change it as account B. If it works, the control is missing.

2. Secrets shipped to the browser

AI builders routinely place API keys in front-end code, where anyone can read them by opening dev tools. Some keys are meant to be public (a Supabase anon key, a Stripe publishable key); many are not (payment secrets, admin tokens, database service keys). Check it: open the Network tab, reload, and search your JavaScript bundle for sk_, service_role, SECRET, and API_KEY. Anything sensitive there must be rotated and moved to the server.

3. Missing server-side authentication

The app looks locked down — protected pages, login screens — but the endpoints that serve data don't actually verify a session. The UI was the only gate. Check it: replay one of your app's data requests from a signed-out browser. If it returns data, the back end trusts the front end, and an attacker skips the front end entirely. This is the core risk behind our builder-specific guides for v0 and Bolt.new.

4. Open database rules

On Supabase or Firebase, the default for a rushed build is often "anyone can read everything." Row Level Security is off, or the security rules allow public reads. Check it: in your database dashboard, confirm Row Level Security is enabled with a per-user policy on every table that holds user data. This is the make-or-break check for Lovable apps, which lean heavily on Supabase.

5. Cross-site scripting (XSS)

If your app renders user-supplied text as HTML without escaping it, an attacker can inject a script that runs in other users' browsers — stealing sessions or data. Modern frameworks like React escape by default, but escape hatches (dangerouslySetInnerHTML, innerHTML) reopen the door. Check it: paste <img src=x onerror=alert(1)> into every field. It should appear as literal text, never fire an alert.

6. Claim-versus-reality gaps

Your landing page promises "we never track you"; your app loads three analytics scripts. Your privacy policy names data you don't actually protect. These aren't just embarrassing — under GDPR they're legal exposure, and collecting a single email makes you a data controller. Check it: read your privacy policy and landing page against what the app really does. Our GDPR & privacy checklist walks through the seven things to get right.

7. No way out (missing account deletion)

GDPR's Right to Erasure requires that users can delete their data. Most vibe-coded apps have no delete path at all, and the ones that do often delete the login while leaving the user's records behind. Check it: sign up, delete your account, and confirm the associated data is actually gone — not just the session.

Notice the pattern: five of these seven live at the boundary between the browser and your backend. Secure that boundary and you've closed most of the risk.

How to actually stay on top of this

The problem isn't knowing the checks — it's running them every time you ship, when you're moving fast and the app "looks fine." That's the discipline vibe coding removes and the one your users depend on. Two ways to keep it:

• By hand, on a checklist. Our general testing guide and the builder-specific guides for Lovable, Bolt.new, and v0 give you the exact steps. The security-holes guide goes deeper on the five technical ones.
• Automatically, on every deploy. Blinkof.ai runs all seven checks against your live URL — signing up, replaying requests without a session, probing for cross-tenant leaks, reading your bundle, checking your privacy claims — and returns a report where every finding comes with a paste-ready fix prompt matched to your stack. You can even wire it into CI so a new critical fails the build.

However you do it, the goal is the same: be the skeptical human the AI wasn't, before a real one shows up.