Built Your App with Lovable, Bolt or v0? A Vibe Coding Security Checklist Before Real Customers

An app built with Lovable, Bolt, v0, Replit or Cursor can work perfectly in a demo and still be unsafe for real customers. These tools write code from a description, an approach now called "vibe coding", and they optimise for "it works when I click it". The usual gaps are open databases, leaked keys and missing permission checks. All of them can be fixed before launch.

Below: the evidence, the seven most common problems and their fixes, and a production-readiness checklist. Prefer to hand the work to a team? Our SaaS product development service builds sign-in, the data model and permission checks on every request properly from day one.

Vibe coding security: AI writes working code, not necessarily safe code

• Veracode's 2025 GenAI Code Security Report tested more than 100 language models on 80 coding tasks. The code worked, but in 45% of cases it introduced a security weakness from the OWASP Top 10, the standard list of the most common web vulnerabilities. Security didn't improve as models got better at writing working code.
• CVE-2025-48757 recorded a real-world example: insufficient database access rules (Supabase "Row Level Security") in Lovable-generated sites let unauthenticated attackers read or write database tables. The researcher who reported it said 170 of the 1,645 live Lovable apps he scanned were affected. Lovable disputes the CVE, saying each customer is responsible for their own app's data. That is the point: the tool won't secure your data for you.
• Security firm Escape analysed more than 5,600 public apps built on vibe coding platforms and found over 2,000 vulnerabilities, 400+ exposed secrets (such as API keys) and 175 cases of exposed personal data, including medical records and bank details.

None of this means the tools are bad. A working demo is simply not the same as a product that is safe to launch.

The seven most common problems in AI-built apps

1. The database is open to anyone

Many AI builders pair with Supabase or Firebase, where the browser talks to the database directly. That's safe only if every table has rules saying who can read and write which rows. Prototypes often skip them or allow everything, so anyone with the browser's developer tools can read every customer record.

Fix: turn on Row Level Security (or Firebase rules) for every table, write policies per table ("users can only read their own orders"), and test them while logged in as a different user.

2. Secret keys are in the front end

Payment, email and AI provider keys sometimes end up in browser code, where anyone can copy them. A leaked AI key can run up a large bill in hours; a leaked payment key is worse.

Fix: move every secret to the server (an API route or edge function). Rotate any key that was ever in the browser bundle: assume it has been copied.

3. Checks happen only in the interface

A prototype often hides the "delete" button from non-admins but doesn't block the request itself. Anyone calling the API directly can do what the interface was meant to prevent.

Fix: enforce permissions on the server for every action, never just in the UI.

4. No real error handling

Demos assume everything succeeds. Production meets expired sessions, failed payments, slow networks and double-clicks.

Fix: handle failures explicitly, show a useful message, and make payments and bookings safe to retry without duplicates.

5. No backups, no environments

Many prototypes have one database, edited live, with no backups and no test environment.

Fix: automated daily backups (and a tested restore), separate development and production environments, and database changes made through migrations rather than by hand.

6. Nothing is monitored

If the app breaks at 2am, who finds out? Usually the customer.

Fix: error tracking, uptime checks and basic logs, so you hear about problems before customers do.

7. Nobody can maintain the code

AI-generated codebases often have duplicated logic, inconsistent patterns and no tests, so each new feature is slower and riskier to add.

Fix: a short refactor of the core flows, a few automated tests for what must never break (sign-up, payment, the main action), and notes on how the pieces fit together.

Production-readiness checklist for vibe-coded apps

Work through this before inviting real users:

Security

• Every database table has access rules, tested as a different user
• No secret keys in front-end code; all exposed keys rotated
• Permissions enforced on the server for every action
• Rate limits on sign-up, login and anything that costs you money (AI calls, emails, SMS)
• Dependencies updated, with no known critical vulnerabilities (our guide to npm supply-chain attacks explains why)

Reliability

• Automated backups, and a restore you have actually tested
• Separate development and production environments
• Error tracking and uptime monitoring switched on
• Payments and bookings safe to retry

Legal and trust

• Privacy policy that matches what you actually collect
• Cookie consent if you serve users in the UK or EU
• A way for users to delete their account and data
• AI chatbot serving people in the EU? Since 2 August 2026, the EU AI Act requires that users are told they are interacting with an AI, unless it's obvious

Maintainability

• Code in version control (Git), not only inside the builder
• Tests for sign-up, login, payment and your core feature
• A README explaining how to run and deploy the app

Should you rebuild or harden your AI-built prototype?

Usually you don't have to throw the prototype away. A sensible approach:

• Keep the product decisions, screens and flows: the valuable part of the prototype, already tested with real people.
• Harden the data layer, authentication and anything touching money first.
• Rebuild only the parts that are both important and unmaintainable, one at a time, while the app keeps running.

Rewrite fully only when the foundations (data model, authentication, hosting) can't support where the product is going. Multiple organisations with separate data, for example, is hard to bolt on later (our guide to multi-tenant SaaS architecture on PostgreSQL explains why).

The bottom line

AI builders are the best way yet to find out whether an idea has legs. Use them for that. Before strangers trust your app with their data or money, lock down the database, move the secrets, enforce permissions on the server, and add backups and monitoring. It costs far less than a breach, and it turns a demo into a product.

Frequently asked questions

Want a second opinion before you launch? Book a free consultation and we'll go through your app's setup with you.

Sources

• Escape, "Methodology: How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms": https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/
• Veracode, 2025 GenAI Code Security Report (July 2025): https://www.veracode.com/resources/genai-code-security-report/
• CVE-2025-48757 (CVE record, including the supplier's dispute): https://www.cve.org/CVERecord?id=CVE-2025-48757
• Supabase documentation, Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
• OWASP Top 10: https://owasp.org/www-project-top-ten/
• EU AI Act, Article 50 (transparency obligations): https://artificialintelligenceact.eu/article/50/