Vibe coding - building apps primarily by prompting AI rather than writing code by hand - is genuinely productive, but it isn’t automatically safe. The tools generate working features quickly; they don’t automatically guarantee the security properties a real product needs before it handles other people’s data or money.
This isn’t a reason to avoid AI app builders. It’s a checklist: the specific things to verify before you consider a vibe-coded app production-ready, based on the most common real issues we’ve seen across builder-generated projects.
Why AI-generated apps can have security gaps
AI builders optimise for producing a working feature from your prompt. If you ask for ‘a dashboard showing tasks,’ you’ll get one - but nothing in that prompt tells the AI whether task data should be strictly isolated per user, or whether an API endpoint needs rate limiting. Security requirements are often implicit, and implicit requirements are exactly what AI assistants are most likely to miss unless you ask for them explicitly.
Risk 1: Missing per-user data isolation
The most common and most serious issue: an app where, with the right request, one user can read or modify another user’s data. In Supabase-backed builders (Lovable, Bolt.new, Softgen), this almost always traces back to missing or incomplete Row Level Security policies.
Risk 2: Exposed API keys and secrets
Every backend integration has a public key (safe in frontend code) and a secret key (must never appear client-side). AI builders sometimes place a secret key where it’s visible in the browser bundle if not explicitly instructed otherwise - this applies to Supabase’s service_role key, Stripe’s secret key, and any third-party API key.
- Check your deployed app’s browser network tab and page source for any key beyond the intended public/anon key.
- Confirm secret keys are only referenced in server-side code (Edge Functions, API routes) - never in client components.
Risk 3: Incomplete authentication checks
It’s common for an AI-generated app to correctly gate the main UI behind login, while leaving an underlying API endpoint reachable without authentication. A user interface check is not the same as a server-side check - always verify that the actual data access, not just the visible page, requires authentication.
Risk 4: Broken billing state (not strictly security, but high-impact)
AI builders frequently generate a working Stripe checkout flow but skip the webhook handler that updates a user’s plan after payment. This isn’t a security hole in the traditional sense, but it means users can end up unbilled-but-active, or paid-but-locked-out - a real business risk. See our Stripe billing guide for the correct flow.
Pre-launch security checklist
- Row Level Security (or equivalent) enabled and tested with two separate accounts.
- No secret keys visible in browser network requests or page source.
- Every data-access endpoint requires authentication server-side, not just the UI.
- Stripe (or other payment) webhooks correctly update billing status, verified with a real test transaction.
- Rate limiting or abuse protection on any public-facing form or API endpoint.
Key takeaways
- AI builders generate working features, not automatically secure ones - security requirements must often be stated explicitly.
- Missing Row Level Security is the most common and most serious real-world issue in AI-generated apps.
- Always verify secret keys never appear in client-side/browser-visible code.
- A UI login screen is not the same as server-side authentication on the underlying data access.
- Run through the pre-launch checklist before any vibe-coded app handles real user data or payments. If you use Claude Code, the trust question for connected tools is covered in Claude Code MCP servers.
Common questions
Is it safe to launch an app built with Lovable, Bolt.new, or similar tools?
It can be, after a security review. These tools generate real, working applications, but you should explicitly verify Row Level Security, check for exposed secret keys, and confirm authentication is enforced server-side - not assume these are handled by default.
What is the most common security mistake in vibe-coded apps?
Missing or incomplete Row Level Security (RLS) on Supabase-backed apps, which can let one user access another user’s data. Testing with two separate accounts is the simplest way to catch this before launch.
How do I check if my AI-generated app has exposed secrets?
Open your deployed app’s browser developer tools, check the Network tab and page source for any API key beyond the intended public/anon key. Secret keys (like a Stripe secret key or Supabase service_role key) should never appear in anything sent to the browser.
Do I need a developer to review a vibe-coded app before launch?
Not necessarily for a small project, if you methodically work through a security checklist like the one above. For an app handling sensitive data or significant payment volume, a professional review is a reasonable additional safeguard.