Is your Lovable app safe? A security checklist for vibe-coded apps

If you built an app with Lovable, Bolt, Replit, Cursor or Base44 and real people are about to put their details into it, check these ten things first. Most of them take minutes to check and are the cause of nearly every vibe-coded app breach on record.

Why this matters now

In May 2025 a researcher checked 1,645 apps from Lovable's own showcase and found 170 leaking user data, because their databases had no access rules (CVE-2025-48757). In October 2025 Escape.tech scanned 5,600 public vibe-coded apps and found more than 400 exposed secret keys and 175 cases of exposed personal data. In each case the tool did what it was asked. Nobody asked the security questions.

In New Zealand there is a second reason. Under the Privacy Act 2020 the business that collects personal information is responsible for it, and a breach likely to cause serious harm must be reported to the Privacy Commissioner. That business is you, not the tool.

The checklist

1. Database access rules are on for every table. In Supabase, Row Level Security must be enabled, and policies must say who can read and write each row. A policy of true looks like protection and is not.
2. No secret keys in the browser. Open your site, open the developer tools and search the JavaScript for "sk_", "service_role" and "key". The Supabase anon key is meant to be public; the service role key, Stripe secret keys and OpenAI keys are not.
3. No secrets in your git history. A key deleted in a later commit is still in the history. If one was ever committed, rotate it.
4. Access checks live on the server. Hiding the admin button is not security. Try opening another user's record by changing the ID in the address bar.
5. Paid features are rate limited. Anything that costs you money per use (AI calls, SMS, email) needs a limit per user, or a script can run up your bill overnight.
6. Payments are confirmed by Stripe, not the browser. Orders should be marked paid only when a signed Stripe webhook says so, and retries should not create duplicate orders.
7. File storage is private by default. Uploads such as ID photos and invoices should not sit in a public bucket.
8. There is a staging copy. Changes should be tried somewhere other than the live app, with its own database.
9. There are backups, and you have restored one. A backup you have never restored is a hope, not a backup.
10. Someone gets told when it breaks. Uptime and error monitoring that reaches a person, not a dashboard nobody reads.

If you are using Lovable specifically

In April 2026 Lovable disclosed a flaw that exposed source code, credentials and AI chat history for projects created before November 2025. If your project is older than that, rotate every key that has ever been stored in it, even if you have since removed it.

What to do if you find something

Fix the access rules and rotate any exposed key first, then check your logs for unusual reads. If customer data may have been seen, take advice on whether the breach is notifiable.

If you would rather have an engineer go through it, our vibe-coded app rescue service starts with a fixed-price security audit, and you keep building with your AI tool afterwards.