production readiness · 5 min read
Is Vibe Coding Safe? (2026 Answer for Non-Technical Founders)
AI-written code carries a known security flaw about 45% of the time, and you can't see which half you got. Where the risk actually lives, and the line that makes it safe.
Updated 2026-09-06
You built something with Lovable, Bolt or Cursor. It works, people are using it, and now you're searching whether that was reckless. Most of what ranks for this question is written for security teams. This is for the founder or product owner who can't read the code and needs a straight answer.
The straight answer: the code AI writes is about as likely to contain a known security flaw as not, and the reason that matters for you in particular is that you can't tell which half you got. Vibe coding isn't unsafe because the AI is bad at code. It's unsafe when nobody stands between the code and your customers.
What the measurements say
Veracode has been testing the same security tasks against every major model since 2025. In its spring 2026 update, only 55% of the code came back secure. The other 45% carried a known flaw, a figure that hasn't moved in two years while the models got much better at writing code that runs. Cross-site scripting, the flaw that lets one user's input run in another user's browser, passed just 15% of the time. Bigger, newer models were no safer than smaller ones.
Secrets are the other half of the picture. GitGuardian's 2026 report found AI-assisted commits leaked credentials at roughly twice the rate of human ones, and that most keys leaked years ago are still valid today. A key that reaches a public repository or a browser bundle stays live until someone rotates it, and nobody rotates what they don't know about.
Both studies measure code produced with no security guidance in the prompt. That's the vibe coding condition exactly.
The one that happened to people like you
In 2025 a researcher scanned 1,645 apps on Lovable's public showcase and found that 170 of them let anyone read the database using the public key already sitting in the app's JavaScript. Names, emails, phone numbers, personal debt amounts and live Stripe keys. It was assigned CVE-2025-48757.
Nothing crashed. Every one of those apps worked. The tables had been created without row-level security, the lock that says which user may see which row, and the app talked to the database straight from the browser, so the lock was the only protection there was. The AI didn't turn it on and no one checked.
That's the shape of vibe coding risk. It doesn't show up in the preview, because the preview shows you what the app does, not what it lets a stranger do.
Where the risk actually lives
Nearly every incident in this category traces back to one of three places.
- Sign-in and who can see what. Authentication, permissions, row-level security.
- Secrets. API keys in the browser bundle, in the repository, or in a screenshot posted while asking for help.
- Money and messages. Payments, refunds, anything that emails customers or charges a card.
Everything else can't leak a database. A copy change, a layout fix, a new form field, a colour, spacing on mobile: the worst a mistake there does is look wrong, and you'll see it in the preview. That split is the whole answer to the question. Vibe coding is safe for the second category and not for the first, and the tools don't tell you which one you're in.
What makes the risky third safe
Not learning to code. A gate. Someone who can read code approves anything that touches those three areas before it ships, the preview runs against real services so what you approve is behaviour rather than a description, and secrets never sit in the client.
That's the line Refinar draws for you. Safe changes go live in seconds, anything that touches sign-in, payments or data access is held for a developer to approve, yours or ours, and the AI never works on your live site. We make it, so read that with the usual salt. The line holds whether or not you use us.
A five-minute check you can do today
- Search your live site for keys. Open it, press F12, go to Sources and search the JavaScript for
sk_live,service_roleandAKIA. A hit means rotate that key now. - Check the locks on your database. In Supabase, open Advisors and look for tables with row-level security disabled. A table without it is public.
- Type your domain followed by
/.env. Anything other than a not-found page is an emergency.
If any of these fail, fix that before you do anything else, then run the full production readiness checklist.
So, is it safe?
For copy, layout and additive UI, yes, and it's faster than waiting for a developer. For sign-in, secrets and money, not without a person in the loop, and no amount of prompting changes the odds. The boundary map lists what falls on each side, and how to review AI-generated code without being a developer is what to do once you're the person in the loop.