Is your vibe-coded app safe for real customers? A security checklist for Lovable, Bolt, Replit and v0 apps

The short answer

Lovable is not unsafe in itself, and neither are the others. A typical AI-built app has three layers: the front end, which runs in the visitor's browser and whose code anyone can read; server-side functions (Edge Functions in Lovable); and a database, which for Lovable is a Supabase-based Postgres. Lovable's own security guide puts it plainly: the front end is public and must never be trusted, and the database, through its row-level rules, decides who can read what.

When those rules are missing or wrong, the app still looks perfect on screen, while anyone who knows where to look can ask the database directly for every user's data. Lovable's security page is explicit about who owns that risk: you are responsible for making sure your app meets the security requirements of its use case, especially if it handles sensitive data.

What the platforms check for you

As of September 2026, according to each platform's own documentation:

• Lovable runs a Quick scan whenever you open the publish dialog: database access rules (tables without per-row control, rules that let everyone in), password protection and known-vulnerable npm packages. A Deep scan, run from the project's Security view, reads your code for authorization flaws, endpoints callable without signing in, injection, hardcoded secrets, payment manipulation and personal data leaking into errors or logs. Both scans are free. Lovable can auto-fix some recent critical database and dependency findings, and there is a setting that blocks publishing while critical findings are open. Without it, you can still publish; Lovable strongly discourages it.
• Lovable also detects API keys pasted into the chat and offers to store them as Secrets: encrypted, injected only into server-side functions, never shipped to the browser, and write-only once saved.
• Bolt added a security audit on publish in July 2026. It is free, covers access control, authentication, business logic, database policies including row-level security, secrets in code and injection, applies the mechanical fixes itself and flags the architectural ones for you. Bolt calls it a first pass, not a replacement for dedicated security tooling, and it does not block publishing.
• Replit has a Project Security Center. Automatic dependency scans are free; Agent security scans of your code and deeper Level 3 scans (black-box testing of the running app plus code review) need a paid plan. You can choose to block publishing when critical vulnerabilities are found.
• v0's security page focuses on keeping secrets on the server: it warns when sensitive values use the NEXT_PUBLIC_ prefix (which ships them to the browser) and can move that code into server-side Route Handlers or Server Actions.

Why a scanner is not enough

In March 2025, researcher Matt Palmer checked 1,645 Lovable apps and found 303 poorly protected endpoints across 170 projects, about 10%. Exposed data included emails, names, phone numbers, third-party API keys, and payment and subscription records, and he only looked at each app's homepage, never behind a login. It was published as CVE-2025-48757 in May 2025; the cause was insufficient row-level security policies. In October 2025, security company Escape looked at more than 5,600 apps built on AI platforms (over 4,000 of them on Lovable) and reported more than 2,000 vulnerabilities, 400+ exposed secrets and 175 instances of exposed personal data, including medical records and IBANs.

The platforms have improved a lot since then. But a scanner still cannot read your business rules. It can tell that a table has a policy; it cannot tell whether a patient should see only their own appointments or their family's too. A policy can exist and still be wrong, and nothing on screen will warn you. Lovable itself says its scans do not replace a thorough security review.

Row-level security on every table

If your backend is Supabase (Lovable Cloud runs on it, and so does any app connected to your own Supabase project), row-level security (RLS) is what keeps each user inside their own data. Supabase's docs are blunt: a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and on many projects new tables start with grants for anonymous visitors already in place. Turning RLS on with no policies blocks access; turning it on with sloppy policies gives you a false sense of safety.

Three traps the Supabase docs call out:

• A policy like "to anon using (true)" lets every unauthenticated visitor read every row. Fine for a public catalogue, never for customer data.
• With no signed-in user, auth.uid() returns null. Good policies check for that explicitly instead of relying on the comparison failing quietly.
• Views created by the postgres user bypass RLS by default, so a view over a protected table can hand out exactly the rows its policies were meant to hide.

Which keys can live in the browser

Your app ships with a Supabase publishable key (the older name is anon key). That is by design: it is meant to be public, and what it can do depends entirely on your RLS policies. With good policies, seeing it gets an attacker nothing; with bad ones, it is all they need. Escape found these keys in the JavaScript bundles of many apps alongside misconfigured RLS: the problem was never the key, it was the rules behind it.

The secret key (formerly service_role) is a different animal: it bypasses every RLS policy. Supabase says it must never go in a browser, a shipped app or source control. The same goes for Stripe secret keys, OpenAI keys and anything else that costs you money; Lovable treats any secret that reaches front-end code as compromised. As of September 2026, Supabase plans to retire the legacy anon and service_role keys by the end of 2026, so if you run your own Supabase project, move to the new publishable and secret keys now.

Authentication and roles

Lovable's rule is short: every access decision happens on the server, never in the browser. Hiding the admin button from non-admins is good UX and zero protection, because anyone can call your database or your functions without going through that button.

Watch where roles are stored, too. Supabase warns that user_metadata can be updated by the signed-in user, so it is no place for an "is admin" flag. Keep roles in app_metadata, which users cannot change, or in a separate table protected by RLS.

Payments and webhooks

If you take payments with Stripe, never unlock anything just because the customer reached your thank-you page. Stripe says you cannot rely on that page alone, because a customer can pay and lose their connection before it loads. The reliable signal is the webhook Stripe sends to your server when the payment completes.

And that webhook has to be verified. Stripe signs every event in the Stripe-Signature header; your handler should check it against the endpoint's signing secret (the one starting with whsec_) before acting. Skip that and anyone who finds the URL can post a fake "payment succeeded".

Files, rate limits and backups

Three things nobody notices until they break:

• File storage. In Supabase, a public bucket serves any file to anyone who has its URL. Invoices, ID scans and customer photos belong in private buckets, with policies saying who can upload, read or delete each file.
• Rate limits. Supabase rate-limits Auth out of the box, for example 30 sign-ups or sign-ins per 5 minutes and 2 emails per hour through its built-in email provider. Your own functions, like the one that calls a paid AI model or sends messages, need their own limit so nobody can call them thousands of times on your bill; Supabase documents how to add one with Upstash Redis.
• Backups. Lovable Cloud lets you restore backups from its Database section. On your own Supabase project, the Free plan has no automatic backups (Supabase suggests exporting your data yourself), Pro keeps 7 days of daily backups and Team keeps 14.

The checklist

Before you invite real customers, or today if you already have them:

1. Run every scan your platform offers (Lovable's Quick and Deep scans, Bolt's audit, Replit's Security Center) and fix everything critical.
2. Turn on the setting that blocks publishing with critical findings, where your platform has one.
3. Confirm RLS is enabled on every table that holds user data, then read each policy and look for any that let everyone in.
4. Create two test accounts and try to read the first account's data while signed in as the second. If you can, something is wrong.
5. Search your front-end code, and your GitHub repo if you sync one, for any key other than the Supabase publishable key. If one turns up, rotate it with the provider and store the new one as a server-side secret.
6. Check where the admin role lives and that admin checks run in the database or on the server, not only in the UI.
7. If you take payments, confirm orders are marked paid from a verified webhook, not from the success page.
8. List your storage buckets and make private anything that should not be public.
9. Put a rate limit on every function that costs money or sends messages.
10. Find out how you would restore your data tomorrow if something got deleted, and actually try it once.

When to get a second pair of eyes

If your app only collects waitlist emails, this checklist and your platform's scans may be enough. Get a review when you store health data, ID documents or anything about minors; when you take payments inside the app; when different kinds of users (customers, staff, admins) should see different things; or when you cannot say for sure what the policies your AI tool wrote actually do. A broken policy throws no error. The app just keeps working.

What I do at Omplia

I review apps built with Lovable, Bolt, Replit and v0 before they get customers, or after: RLS table by table with test accounts, keys, roles, payments, storage and backups, and I write down what I found and what I changed. If your app is already in good shape, I will tell you so.

App work starts from 2,900 €, plus an optional monthly care plan. The final price depends on what needs doing and is fixed in writing before I start. The first look at your link is free.