• Agents
  • Pricing
  • Blog
Log in
Get started

Security for apps built with AI. Paste a URL, get a report, fix what matters.

Product

  • How it works
  • What we find
  • Pricing
  • Agents
  • MCP Server
  • CLI
  • GitHub Action

Resources

  • Guides
  • Blog
  • Docs
  • OWASP Top 10
  • Glossary
  • FAQ

Security

  • Supabase Security
  • Next.js Security
  • Lovable Security
  • Cursor Security
  • Bolt Security

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • Imprint
© 2026 Flowpatrol. All rights reserved.
Lovable Security

You shipped with Lovable.
Is your database locked?

Most Lovable apps leave their entire database readable to anyone who opens the page. 47% of the ones we scanned had critical issues. 88% had high-severity ones. The average app had 5.2 findings. The good news: most are fixable in under an hour — once you know where to look.

47%
had critical issues
100-app study
170+
live apps with open databases
CVE-2025-48757
303
open endpoints confirmed
5.2
avg findings per app

What goes wrong in a Lovable app?

Lovable builds a React frontend backed by Supabase. The stack is solid. The problem is what the AI leaves out: per-user access rules, server-side ownership checks, and keeping secrets off the browser. These gaps follow the same pattern across almost every Lovable app.

Critical

Your database is wide open by default

Lovable creates Supabase tables without any per-user access rules (Row Level Security, or RLS). With no RLS, the public key that ships in your page source becomes a full-access pass to every row in every table.

CVE-2025-48757 confirmed this pattern across 170+ live apps and 303 open endpoints. Personal debt records, home addresses, API keys, and user logins were all grabbable by anyone with a browser.

High

Your Supabase key is baked into the page source

Every Lovable app embeds the Supabase URL and public key in the JavaScript bundle. That is fine when per-user access rules are on. When they are off, it is like publishing your database password.

In our 100-app study, 54% of all apps had secrets sitting in frontend code. Lovable apps had the highest rate because the key is always there and the access rules almost never are.

High

User A can read User B by changing an ID

Lovable builds login flows that look right on the happy path — you log in, you see your data. But API routes rarely check that the record you are asking for actually belongs to you. Change a 1 to a 2 in the URL and you are reading someone else.

This pattern (called IDOR, Insecure Direct Object Reference) showed up in 41% of multi-user apps in our study. Lovable apps were hit harder because the AI builds CRUD routes without any ownership check.

Medium

The browser has no guardrails

Lovable apps typically ship without the browser-side security headers that block injected scripts (Content Security Policy, or CSP), stop clickjacking, or force HTTPS. Some even leave their APIs open to any origin.

47% of the 100 apps we tested were missing these basic headers. Without CSP, a cross-site scripting bug is much easier to turn into account takeover.

Why is the database the biggest risk in Lovable apps?

Every Lovable app puts the Supabase URL and public key in the JavaScript bundle. That is by design — Supabase expects that key to be public. The whole safety model is that per-user access rules on each table decide who can read what.

Lovable's AI skips that step. It creates tables, writes queries, builds the UI, and never turns on the access rules. The result: anyone who opens DevTools, copies the two keys, and runs a Supabase call gets full read and write access to every table. No login. No token. No clever trick.

This was formally written up as CVE-2025-48757 in May 2025. Researchers confirmed 170+ live apps and 303 open endpoints. What came out included personal debt records, home addresses, API keys, and user logins. One researcher walked into multiple Lovable showcase apps in 47 minutes.

How Flowpatrol checks your Lovable app

Paste your URL. Flowpatrol scans your live app the way an attacker would — and hands you the report instead.

Finds secrets in your page source

Scans your JavaScript bundles for Supabase URLs, public keys, service-role keys, and anything else that should not have shipped to the browser.

Tries to read your tables

Uses the keys it finds to hit every table from a logged-out session. If your per-user access rules are missing or broken, you will see exactly which tables leaked.

Walks your login end-to-end

Checks that login is actually enforced on the server — not just in the UI. Tests whether one user can read another, escalate to admin, or skip the login wall.

Related reading

The Lovable RLS Vulnerability: 170+ Apps Exposed

Full case study on CVE-2025-48757 and how one AI platform shipped the same flaw across hundreds of apps.

How to Secure Your Lovable App Before You Launch

Step-by-step guide to fixing the most common Lovable security issues in under an hour.

Same Default, Four Breaches

How the same BaaS default shipped to production in Moltbook, Tea, Cal AI, and Quittr.

Supabase RLS: The Security Feature Your AI Forgot

A deep dive into Row Level Security and why it is the single most important setting in your Supabase project.

Check your Lovable app in five minutes.

Paste your URL. See exactly what's exposed. Fix what matters before your users find out.

Try it freeWhat we find