What we find when we take vibe-coded apps into production

You have built an app with an AI tool such as Lovable, Bolt or Replit and now wonder if it is safe for real users. We have audited AI-built (“vibe-coded”) apps several times and brought them into production. The recurring problems are exposed secrets in client-side code, Supabase tables with row-level security never configured, access control enforced only in the front end, and missing input validation. Alongside these security gaps, we regularly find missing staging environments, backups and tests. This article explains what we see, why it happens, and how to decide between fixing the code or rebuilding.

Security gaps we see in AI-built apps

Veracode’s 2025 GenAI Code Security Report (July 2025) found 45% of code samples generated by more than 100 LLMs failed security tests and introduced OWASP Top 10 vulnerabilities. That is a share of test samples, not real-world apps, but it matches what we encounter. When we audit a vibe-coded app we usually find a cluster of specific weaknesses.

Exposed secrets in client-side code

A common pattern is API keys and credentials committed to the browser bundle. The AI builder optimises for a working demo, so it places keys where the front end can call the service directly. During an audit we inspect the shipped JavaScript and network calls to confirm what is exposed. Fixing it means moving secret operations to a server function, reading keys from environment variables, and adding a gateway that validates requests. The leaked key is revoked at the provider.

Supabase tables without row-level security

Many projects use Supabase but never enable row-level security. Supabase’s documentation states that a table in an exposed schema without RLS is readable and writable by any role with a grant on it. We check the database policies and often find open tables. The repair involves writing policies per table that match the application roles, then running queries as each role to confirm isolation. Security researcher Matt Palmer’s disclosure behind CVE-2025-48757 found inadequate Supabase Row Level Security on 303 endpoints across 170 Lovable projects, about 10% of the 1,645 projects he analysed, with exposed data including names, emails, phone numbers, API keys and payment details, and some endpoints also allowed writes. Lovable was notified on 21 March 2025 and the CVE was published on 29 May 2025. We describe these as exposed, not hacked.

Access control only in the front end

Another recurring finding is access rules baked into the UI rather than the database. The demo user is always an admin, so the AI never writes server checks. We test by calling endpoints without a session to see if data returns. The fix is to enforce permissions in the back end through middleware that checks the session token on every protected route, and to remove trust from the client. OWASP Top 10:2025 lists Broken Access Control as A01 and Security Misconfiguration as A02.

Missing input validation

AI-written code often skips validation on forms and APIs. The tool produces what you asked for, not what you forgot to ask. We probe inputs with unexpected values during the audit. Adding server-side validation at the API boundary and encoding output to prevent injection is straightforward but must cover every entry point. The Veracode report also noted AI tools failed to defend against cross-site scripting in 86% of relevant samples, and newer or larger models were not more secure than older ones.

Why AI builders produce these patterns

The incentive for an AI builder is a functioning demonstration, not a hardened system. It optimises for the happy path where the demo user has full rights, whilst the safeguards you did not mention are omitted. The model does not understand your business constraints unless you state them, so compliance and multi-tenant separation are absent. Pearce et al., “Asleep at the Keyboard?” (IEEE Symposium on Security and Privacy 2022, NYU and University of Calgary) found about 40% of 1,689 programs generated by GitHub Copilot across 89 scenarios were vulnerable. The model writes the code you requested and stays silent on the protections you omitted. This is the nature of prompt-driven development rather than a flaw in any single tool.

Non-security gaps that block production

Beyond security, we see engineering basics missing that stop a safe launch.

No staging, backups or error logging

A frequent state is a single live environment with no staging, no automated backups and no error tracking. If a change breaks something, there is no safe place to test and no record of what failed. We set up separate environments, configure backups and add structured logging so issues are visible. Without these, even a secure app is a risk to run.

Unreadable single repository

Founders often receive one large repository they cannot read. Every concern sits in the same codebase with no tests, especially around payments. We map the code, extract the payment logic and write tests before any modification. We document the modules as we go, so the founder receives a readable map.

The Supabase anon key versus the secret key

Founders sometimes panic that the anon key is public. Supabase describes the publishable (anon) key as safe to expose because it only reaches what Row Level Security allows. The secret (service_role) key bypasses RLS and must never be used in the browser. If you see the anon key in client code, that is expected. If you see the service_role key, that is the urgent problem to rotate and remove.

Harden, partially rebuild, or start again

The honest decision rests on signals we read during the audit, not a guess. We check four things.

First, is authentication concentrated or scattered? If permission checks are only in the front end and spread across components, the app needs structural change.

Second, does the schema carry tenant IDs? In a multi-user product, if tables lack a tenant column, retrofitting isolation is painful and a partial rebuild may be cheaper.

Third, is payment logic reachable from the client? When the browser can directly call a payment API with a secret, we extract that into a server-side service with tests.

Fourth, is there any test at all, particularly around payments? No tests means we cannot safely change code, pushing towards a rebuild of the risky modules.

If the data model is sound and only policies and tests are missing, hardening the existing code makes sense. Our Hardening service covers that. If the architecture fights every change, a partial rebuild of the risky modules may be cheaper, for example by extracting the payment service into a separate tested component whilst keeping the UI. When the core is unsalvageable, a full rebuild on a proper stack is the better spend.

Our process and what it costs

We start with a free call to understand your app. The Vibe Code Rescue Assessment costs £995 + VAT and includes a written report and a 45-minute walkthrough. The fee is credited if you book a fix within 30 days. Remediation options are Hardening at £2,000 to £8,000 and Productionise & Ship at £5,000 to £15,000. You can read the self-serve version in our vibe-coded app production checklist, but this page reflects what we actually encounter. For hands-on help, visit our Vibe Code Rescue service.

Frequently Asked Questions

How do I know if my vibe-coded app is insecure?

A clear signal is data returning from an API without a login. When we review such apps we often find tables open because row-level security was never set. You can check Supabase settings or review the browser network tab for secret keys. If you see a service_role key in client code, treat it as urgent. A professional assessment gives certainty about the full picture.

What is the difference between the Supabase anon and secret keys?

The anon key is designed to be public, so finding it in your browser code is normal. The service_role key bypasses row-level security and must stay on the server. If you are unsure which you have exposed, open the Supabase dashboard and rotate any secret key immediately. We explain this during the assessment walkthrough.

Can a vibe-coded app be fixed rather than rebuilt?

Often yes, if the data model is sound. We look at whether auth is scattered, if tenant IDs exist, if payment logic sits in the client, and whether any tests are present. Where only policies and tests are missing, our Hardening service at £2,000 to £8,000 resolves it. Otherwise a partial or full rebuild may be cheaper.

What does the Vibe Code Rescue Assessment include?

It costs £995 plus VAT and includes a written report plus a 45-minute walkthrough. We inspect your code and infrastructure for the issues described above and explain each finding plainly. If you book a fix within 30 days, the fee is credited. You can begin with our checklist too.

Next steps

If you are weighing up whether to fix or rebuild your app, our team can give you a frank assessment on a free call. Visit our Vibe Code Rescue service or read whether vibe coding is secure for the short answer.