We Built Our App With AI and It Has Security Holes — Should We Rebuild It?

First, take a breath. Shipping something that works is the hard part, and most founders never get there. The fact that you built a real product with AI and customers are using it is a genuine achievement. The security holes are not a sign you did it wrong — they are the predictable, almost universal gap in how AI tools generate code today. Knowing they exist puts you ahead of the people who haven't looked.

Second, the honest answer to "should we rebuild?" is usually no, not the whole thing. The features, the screens, the flow your customers like — that stays. What needs rebuilding is the thin, dangerous layer underneath: how data is stored, who is allowed to read it, and where your secrets live. That is a contained job, not a teardown.

Why vibe-coded apps share the same security holes

This is not bad luck specific to your build. It is structural. Veracode's 2025 GenAI Code Security Report tested code from more than 100 large language models and found that 45% of generated code samples failed security tests, introducing the kind of flaws on the OWASP Top 10 list. Tellingly, newer and larger models did not score better — the report concluded this is baked into how AI generates code, not a gap the next model release will close.

The reason is simple once you see it. An AI coding assistant optimises for code that runs and matches what you asked for. You asked it to "let users save their profile" — and it did, beautifully. You did not ask it to "make sure user A can never read user B's profile," because you didn't know that was a separate thing you had to ask for. As the security firm Tenzai put it after auditing five popular tools, the agents "lack this 'common sense' and depend mainly on explicit instructions." The functional request gets met. The unspoken security requirement does not.

So vibe coded app vulnerabilities cluster around the same few mistakes regardless of who built the app or which tool they used. That is good news for you: if the problems are predictable, the fixes are too.

The three holes that let strangers read your customers' data

When founders tell us "anyone could read our data," it is almost always one of three things — often all three at once.

1. Database access controls were never switched on

This is the big one, and the most dangerous. If you use Supabase, Firebase, or a similar backend, your database has a feature called Row Level Security (RLS) — the rule that says "a logged-in user can only see their own rows." AI tools frequently scaffold projects with Supabase RLS disabled by default, because that is the fastest way to make the app work in early development. Nobody turns it back on.

The effect is brutal. With RLS off, the public key your app uses to talk to the database becomes an admin-level master key for every table. This is exactly the pattern behind CVE-2025-48757, disclosed in June 2025 by researcher Matan Getz, which affected more than 170 applications built on the Lovable platform — AI was generating database configurations with RLS disabled, leaving customer data and API keys readable to anyone who looked. Wiz Research, scanning real production apps, found the same "overly permissive or disabled Row-Level Security" leaking personal data, IP addresses and confidential records across vibe-coded apps.

2. Secret keys were shipped to the browser

Your app needs keys to talk to other services — your AI provider, your payment processor, your email tool. There are two kinds: public keys, safe to expose, and secret keys, which must never leave your server. AI-generated frontends routinely embed secret keys straight into the JavaScript that downloads to every visitor's browser. Anyone can open the developer console, find your API keys in the client bundle, and start spending your money or reading data on your behalf. Wiz specifically called out hardcoded sk-proj- OpenAI tokens sitting in client-side code. In Escape.tech's October 2025 scan of 5,600 vibe-coded apps, exposed secrets like these turned up in over 400 of them.

3. Login checks run where the user can edit them

The third common vibe coding security hole is authentication that happens in the browser instead of on the server. The app checks "is this person allowed in?" using JavaScript the user fully controls — so a curious visitor can simply delete the check. Wiz found apps "handling password validation entirely in the browser, with credentials embedded directly in JavaScript files," plus admin dashboards and staging environments deployed publicly with no authentication at all. A lock only works if the user can't reach the mechanism. Client-side checks hand them the key.

Across the whole landscape, Wiz Research reported that one in five organisations building on vibe-coding platforms had systemic security risks of this kind. The common thread, as their team noted, is that these issues are "easily preventable" — which is the encouraging part.

How to find out how exposed you actually are

Before deciding anything, get the real picture. You can do a meaningful first pass yourself in an afternoon, no specialist tools required.

• Open your live site, then open the browser developer tools. In the Network and Sources tabs, search the loaded files for "key", "secret", "token", "password". If a secret key (not a public one) shows up, that is hole number two confirmed.
• Check your database dashboard for RLS. In Supabase, open the Table Editor and look at each table's RLS status. Any table holding customer data with RLS "Disabled" or "No policies" is hole number one.
• Try to reach data you shouldn't. Log in as one test user, note the URL or ID for their record, then try to load another user's record by changing the ID. If it loads, your access controls aren't enforcing ownership.
• Test the front door. Open your admin pages and internal tools in a private browser window where you are not logged in. If they load, they are public.

This tells you the severity. A leaked secret key and a wide-open database mean act today. A single missing ownership check on a low-stakes feature means plan the fix calmly. Either way, you now know — and knowing is the difference between a quiet patch and a public incident.

The safe way to rebuild a vibe-coded app

You do not rebuild a vibe-coded app by starting over. You rebuild it in the right order, securing the data layer first because that is where the bleeding is, then hardening the rest while the app keeps running. The sequence we use looks like this.

• Rotate every secret immediately. If keys have been in the browser, assume they are compromised. Generate new ones, store them server-side, and revoke the old ones. This is the one step that can't wait.
• Turn on Row Level Security and write real ownership policies. Every table gets a rule that ties each row to the user who owns it. Until this is done, the database is open regardless of anything else.
• Move authentication and authorisation to the server. Every "is this person allowed?" decision moves out of the browser to code the user can't touch. This is the part most worth rebuilding properly rather than patching.
• Add input validation and rate limits. Validate what comes in, and cap how often anyone can hit your endpoints, so a single bad actor can't drain or poison your system.
• Re-scan, then keep the good parts. Run the checks again, confirm the holes are closed, and leave your working features exactly as they are.

Done in this order, the customer-facing app barely changes. The dangerous layer underneath gets replaced with something built to hold. That is the difference between a panicked rewrite and a calm, surgical rebuild — and it is why most founders who arrive worried about throwing everything away end up keeping 80% of what they made.

When it is genuinely worth bringing in help

Plenty of this you can do yourself, and if your app is small and the stakes are low, you probably should — switching on RLS and rotating keys is within reach for anyone comfortable enough to have built the app in the first place. We would tell you that plainly rather than sell you a rebuild you don't need.

It is worth bringing in a studio when the cost of getting it wrong is high: you are holding real customer data, taking payments, handling anything covered by data-protection rules, or growing fast enough that a breach would be more than embarrassing. The risk of a half-finished fix is a false sense of safety — RLS on three tables out of five looks done and isn't. When you decide to hire a studio to rebuild an AI app, what you are really buying is the certainty that someone who has closed these exact holes before has checked every table, every endpoint, and every key — and can tell you, with evidence, that it is sealed.

Either path is legitimate. The one thing that isn't is leaving it open now that you've seen it. The strangers who scan for AI generated code vulnerabilities are automated, patient, and already looking.