Security guide
Is your vibe-coded app safe to ship?
You built it in a weekend. It works, people are signing up, and somewhere around the third feature you stopped reading the diffs carefully. That is a completely normal way to build with Cursor, Lovable, or Bolt. It is also why so many of these apps go live with the back door open.
The uncomfortable part is that the model did nothing wrong. You asked for a page where a customer can see their orders, and you got one. You did not ask it to verify that whoever requests order 1182 is the person who placed order 1182, so that check does not exist. Security is mostly the half of the work nobody thinks to prompt for.
The four that keep showing up
Every large scan of AI-built apps turns up roughly the same short list. None of it is exotic. It is the unglamorous groundwork an assistant skips while it optimizes for making the demo work.
- The database is not enforcing anything. Supabase ships row-level security as something you turn on, and a model wiring up a table has no particular reason to turn it on. Leave it off and your client-side query can read every row in the table, not just the rows belonging to the person signed in. This is the origin of CVE-2025-48757, a CVSS 9.3 issue in Lovable published in May 2025. The researcher who found it, Matt Palmer, scanned about 1,600 public Lovable projects and found more than 170 of them exposing data to anyone who asked.
- Your keys are in the browser. API keys and database URLs get pasted into client-side code because that is where the code that needs them lives. Anyone can read them with devtools and a minute of patience. The Supabase
service_rolekey is the one that really hurts, because it is designed to bypass row-level security. If it reaches the frontend, every policy you wrote stops mattering. - The only lock is the one you can see. The admin button is hidden unless
user.isAdmin, which looks like access control and is not. Nobody attacking your app is clicking buttons. They are calling the endpoint directly, and the endpoint answers, because hiding a control in the interface does nothing to the route behind it. Wiz researchers put exploitable misconfigurations in roughly one in five of the vibe-coded apps they looked at, with client-side auth logic near the top of the list. - Injection, still, in 2026. String-concatenated queries and unescaped output show up in generated code the same way they show up in tutorials, because that is what the model learned from.
Ten minutes you can spend right now
Before you bring in any tooling, four checks will tell you most of what you need to know:
- Open your Supabase table editor and look for tables with row-level security off. Then open the policies on the tables that have it on, because a policy of
trueis the same as no policy at all. - Search your built frontend bundle for
service_role,sk-, andsecret. Search your git history too. Rotating a key is easy; noticing it leaked eight months ago is not. - Take one authenticated request out of your network tab, replay it with curl and no session cookie, and see what comes back. Then replay it with a second account’s session and someone else’s record ID.
- Ask whichever assistant wrote the app to list every API route that reads or writes user data, then check each one for an authorization check that runs on the server. Models are much better at auditing code than at remembering to secure it in the first place.
Where scanners stop
Do all that and you will still have a gap, which is the difference between a weakness that exists in the code and a weakness an attacker can actually reach. Most tools aimed at this problem read your source, match patterns, and hand back a list of things that might be a problem. The list is long, the false positives are plentiful, and after the second afternoon of triage most founders quietly stop opening it.
Midas works the other end of the problem. It goes at the deployed app the way an attacker would, tries the exploit, and reports the ones that worked, with the steps to reproduce each. A finding on the list means somebody got in. That is a much shorter list, and you can act on all of it.
Questions people ask
Is vibe coding safe?
Safe to build with, not automatically safe to ship. The model writes the feature you asked for, and if you did not ask for authorization checks, secret handling, or row-level security, you did not get them. That is less a flaw in the tool than a gap in the prompt. An AI-built app is production ready once someone has attacked it and the results came back clean, which is a different bar than the code looking fine.
How do I secure a Lovable or Supabase app?
Start with the database, because that is where the worst failures live. Turn on row-level security for every table holding user data and read each policy instead of trusting that one exists. Confirm your service_role key appears nowhere in the frontend bundle, since that key is built to bypass row-level security. Then move authorization out of your React components and into the API routes.
Finally, test the deployed app rather than the source. Only the deployed app can tell you which gaps are reachable in practice.
Can I launch a vibe-coded app to production?
Yes, and plenty of people do. The ones who avoid trouble treat testing as part of shipping rather than something to get to later. Run a penetration test against staging or production, fix what was genuinely exploitable, run it again. The awkward part of building this way is that each new feature is a fresh chance to reintroduce the same four mistakes, so a single audit at launch ages faster than you would like.
Ship fast, without shipping holes
Midas is autonomous penetration testing for teams building at AI speed. Point it at your app and it goes looking for the same things an attacker would, proving each finding by exploiting it, on a subscription that costs a fraction of a traditional pentest.
Related reading: AI agent and LLM penetration testing