Is your Lovable app secure? The 5 most common security gaps
Lovable itself isn't the problem. The gaps appear in the app you build with it. Here are the five most common ones, where to find the Supabase key, how to check Row Level Security in two minutes and what we measure across 454 AI-built apps from the DACH region.
Usually not completely. The Lovable platform isn't the weak spot; the gaps appear in the app you build: tables without Row Level Security, a service_role key in the browser, role checks only in the frontend, keys in the code and missing security headers. In our AI App Radar (October 2026), 25% (47 of 187) of Lovable apps got a Go, 75% (140 of 187) needed work. Whether yours is among them, the free decivo Scan shows in a few minutes.
The essentials
- decivo AI App Radar, run “Panel 2026-10-01”: of 454 apps with a DACH connection, 18% (83 of 454) got a Go, 81% (367 of 454) an Iterate and 1% (4 of 454) a Stop. Lovable alone: 25% (47 of 187) Go, no Stop.
- 24% (109 of 454) of the apps write from the browser straight into the database. Then Row Level Security alone carries the protection. In 13% (57 of 454), a role comparison such as “admin” sat in the shipped JavaScript.
- In 2025 a researcher found insufficient Row Level Security in 170 of 1,645 scanned Lovable projects (CVE-2025-48757, disputed by Lovable). In February 2026, according to a security researcher, 18,697 user records were retrievable in a single app built on Lovable.
- Supabase is replacing the old anon and service_role keys with publishable and secret keys and plans to retire the old ones by the end of 2026 (exact date still open). You find the secret key under Settings → API Keys, and it never belongs in the browser.
- Whether your tables are open, you can check with one SQL query in two minutes. The query is below, ready to copy.
Why almost every AI app has gaps
AI builders like Lovable, Bolt or v0 optimise for one thing: producing something visible in hours. Security is invisible. The AI builds a working login, but whether everyone really only sees their own data behind it, it doesn't check. What vibe coding is and why this happens is in the glossary entry on vibe coding.
The numbers point the same way. A study by Symbiotic Security found at least one flaw in 98% of 1,072 AI-built apps, a critical one in 16%. Our own vibe-code audit shows where it breaks: across 12 typical MVP features, not a single authorization control was met. The AI builds the door but no lock.
That doesn't mean your app is lost. It just means “it runs” and “it's secure” are two different things. Most gaps follow a pattern, and that's exactly what makes them checkable.
The 5 most dangerous security gaps in Lovable apps
1. Database without access control (Row Level Security). By far the most common critical mistake. Lovable apps talk to their Supabase database straight from the browser. Without Row Level Security, any visitor holding the public key can read or change all records, not just their own. That is what CVE-2025-48757 is about.
2. The full-access key in the browser (service_role). Supabase has a public key for the browser and a secret one with full access. If the secret one ends up in the shipped code, all protection is worthless: whoever reads it can read, change and delete the whole database. What makes it special is in the glossary entry on the service role key.
3. Roles are only checked in the frontend. The app hides the admin area if you're not an admin, but the database never asks. Whoever sends the request from the browser themselves still gets the data. The role has to be enforced in the database or on the server.
4. Public keys and .env files. Keys for payment services, AI services or email belong on the server, not in the browser. An accidentally published .env file can often simply be opened via the URL. Both mean other people's costs on your bill or misuse in your name.
5. Missing login checks at sensitive spots. An edge function or API is “protected” but never checks whether the caller is logged in and authorised. In February 2026 a security researcher even found a check with inverted logic in a Lovable app: logged-in users were rejected, anonymous ones let through.
What we measure across 454 AI-built apps from the DACH region
The decivo AI App Radar checks publicly reachable AI-built apps connected to Germany, Austria or Switzerland from the outside, with the same rules as the scan. Run “Panel 2026-10-01”, closed on 2 October 2026, 454 apps, 187 of them built with Lovable. Share per finding; the tracker check runs in the browser and therefore uses the 392 apps with a browser run as its base:
| Finding | Share | Apps |
|---|---|---|
| Browser writes straight into the database | 24% | 109 of 454 |
| Role comparison in the shipped JavaScript | 13% | 57 of 454 |
| Content rendered only in the browser | 25% | 112 of 454 |
| No Content Security Policy | 98% | 444 of 454 |
| No clickjacking protection | 90% | 410 of 454 |
| Trackers fire before consent | 15% | 58 of 392 |
Measured from the outside, without access. A finding is an evidenced signal, not proof of a data leak. The radar publishes frequencies, not individual apps.
Two numbers matter most for Lovable apps. 24% (109 of 454) of the apps write straight from the browser into the database. That's how Supabase is designed and not wrong in itself, but it means only Row Level Security stands between a visitor and the data. And in 13% (57 of 454), a role comparison such as role === 'admin' sat in the shipped JavaScript. Whether the server or the database enforces the same rule again is invisible from the outside. If they don't, the check in the browser is just a hidden button.
Compared with other builders, Lovable doesn't do worse: 25% (47 of 187) of Lovable apps got a Go, against 18% (83 of 454) across all apps. A Go is still no guarantee, and the remaining 75% (140 of 187) are the normal case. All figures, builders and countries are published in the AI App Radar.
The Supabase service role key: what it is and where to find it
Supabase gives every project two kinds of keys. The public one is called anon key in older projects and publishable key in new ones (starting with sb_publishable_). It may sit in the browser and only sees what your Row Level Security policies allow. The secret one is the service_role key, in new projects the secret key (starting with sb_secret_). It bypasses every RLS policy and may read, change and delete any row in any table.
Where to find it: in your project's Supabase dashboard under Settings → API Keys. The new publishable and secret keys are listed there; the old JWT keys anon and service_role sit in the same area under the legacy keys. You have to reveal the secret key first. Copy it only into server-side environment variables, never into a variable prefixed NEXT_PUBLIC_ or VITE_: both are compiled straight into the browser bundle.
What changes in 2026: according to its docs, Supabase plans to retire anon and service_role by the end of 2026, with the exact date still to be confirmed. Creating new keys doesn't disable the old ones; that's a separate step. And Supabase rejects new secret keys in the browser with a 401. That's a safety net, not a licence: outside the browser, for example in a script, a leaked key keeps working.
If the key was public: create a new one immediately, delete or disable the old one, switch your server variables and check what was changed in the meantime. Whether a service_role key sits in your shipped code is checked by the scan rule service_role key in the browser.
Check Row Level Security yourself in 2 minutes
Open the SQL Editor in the Supabase dashboard and run this query. Each row in the result is a table in the public schema without Row Level Security, i.e. a table anyone with the public key can read:
select tablename
from pg_tables
where schemaname = 'public'
and rowsecurity = false;An empty result doesn't mean secure yet. RLS can be on and still allow everything if a policy simply says “true”. The second query lists all policies with their condition:
select tablename, policyname, cmd, qual
from pg_policies
where schemaname = 'public';Look for rows where qual contains only true, and for SELECT, UPDATE or DELETE policies without a link to the user ID (typically auth.uid() = user_id). The Security Advisor in the dashboard also flags tables without RLS. Lovable checks access rules on publish in its built-in security scan; how much that helps depends on whether you act on the recommendations.
Security incidents around Lovable: what is known so far
Searching for “Lovable data breach” turns up three cases worth keeping apart. May 2025, CVE-2025-48757: researcher Matt Palmer had scanned 1,645 publicly showcased Lovable projects and found insufficient Row Level Security policies in 170, affecting 303 endpoints. The CVE was published in May 2025. Lovable disputes it, saying each customer is responsible for protecting their app's data.
February 2026, a single app: according to The Register, a security researcher found 16 vulnerabilities, six of them critical, in an app featured on Lovable's Discover page, including a login check with inverted logic. By his account, 18,697 user records were retrievable, including student accounts. Lovable disputed parts of this: the project contained code Lovable hadn't generated, the database wasn't hosted by Lovable, and acting on the security scan's recommendations is up to users.
April 2026, the platform itself: on 20 April 2026 a security researcher made public that signed-in Lovable users could view chat histories and source code of public projects belonging to other users. Lovable initially denied a data breach; in its statement of 22 April it names a backend change from February as the cause, says the period from 3 February to 20 April 2026 was affected and that the fix took under two hours. According to Lovable, private projects and Lovable Cloud were not affected. If you used keys or real customer data in prompts, check whether the project was public during that period and rotate keys if in doubt. What this means for you under data protection law is covered in Is Lovable GDPR-compliant?
The pattern: two of three cases were in the built app, not in Lovable. That's why “Is Lovable secure?” isn't enough. The better question is: is your app secure?
How to spot them without a developer
You don't need to read code. Much of this is visible from the outside, and that's where the decivo Scan comes in. Enter your public URL: it checks whether a service_role key is in the browser, whether the public key actually returns rows from your database (it only counts, not a single row is fetched), whether .env or .git files are reachable, whether known API keys are in the code, whether roles are checked in the frontend and whether security headers are missing.
It takes minutes, costs nothing, and you give no access to code or database. The result is a clear Go, Iterate or Stop with an explanation, no jargon.
Checks only the operator may trigger run after a proof via DNS record; architecture and code the scan sees with read-only GitHub access. All three tiers are free. What else a Lovable project needs before launch is on the page Is your Lovable app production-ready?; how to handle a wobbling app is in Lovable app not working anymore.
The GDPR factor in the DACH region
In Germany, Austria and Switzerland an open database isn't just a technical problem but a legal one. If personal data is processed without appropriate protection (Art. 32 GDPR) and reaches unauthorised people, that is usually a reportable breach under Art. 33 GDPR, with a 72-hour deadline.
On top come the smaller but common issues: Google Fonts loaded from Google's servers at runtime, trackers that fire before consent and missing information in the legal notice. The decivo Scan checks these privacy signals as a separate area.
To be honest: a scan is a technical classification, not individual legal advice. For your specific case, a data protection officer or lawyer belongs in the mix. What Lovable commits to on the DPA and data location, and which obligations your app has itself, is covered in Is Lovable GDPR-compliant?
What to do when you find a gap
First: don't panic-ask the AI to “make it secure” ten times. That only changes more code without understanding the cause. Prioritise by severity: a service_role key in the browser or an open .env are immediate items (regenerate the key, remove the file), and so are open tables. Missing headers are important but not urgent.
The most important step is database access control. If you're unsure about it, get help before real user data is in there. Getting this wrong is more expensive than any consultation.
After the scan, the result recommends the right path, with the price up front: the immediate mitigation (€540 net, fixed price) closes every open high-severity gap from the scan. The repair plan (€349 net) lists every location in order, so you or your team can fix it yourselves. Repair and stabilisation costs from €1,090, a fixed price from your scan, binding after the repository scan. All paths are on the Vibe Code Rescue page.
Sources
All figures in this article come from the following sources. Retrieved on 20 October 2026.
- decivo — KI-App-Radar DACH, Lauf „Panel 2026-10-01“, Methodik 2026.33 (CC BY 4.0)
- Supabase Docs — Understanding API keys (publishable/secret, Abschaltung der alten Schlüssel bis Ende 2026, Datum noch offen)
- Supabase Docs — Row Level Security
- Supabase Docs — Hardening the Data API (RLS auf jeder Tabelle)
- NVD — CVE-2025-48757: unzureichende Row-Level-Security-Policies in Lovable-Projekten (vom Anbieter bestritten)
- Matt Palmer — Statement on CVE-2025-48757 (170 von 1.645 Projekten)
- The Register — Lovable-hosted app littered with basic flaws exposed 18K users, researcher claims (27. Februar 2026)
- Lovable — Our response to the April 2026 incident (22. April 2026)
- Symbiotic Security — „We scanned 1,072 vibe-coded apps: 98% had security flaws“ (2025)
- decivo Vibe-Code-Audit v1.0 (2026), CC BY 4.0 — 0 % erfüllte Autorisierungs-Kontrollen über 12 Features
- OWASP — Top 10 Web Application Security Risks
An insecure Lovable app is no reason to panic, but a reason to look before real data is in there.
Scan for free nowLovable app security: the key questions
Is Lovable secure?
For the platform itself one incident is known (April 2026, public projects). Most known gaps, however, were in the built app: tables without Row Level Security, keys in the browser, role checks only in the frontend. So whether your app is secure has to be checked on the app, not on the tool.
What is the service role key in Supabase?
The secret key of a Supabase project. It bypasses every Row Level Security policy and may read, change and delete any row in any table. In new projects it's called the secret key and starts with sb_secret_. It belongs on the server only, e.g. in API routes, server actions or edge functions.
Where do I find the service role key in Supabase?
In your project's Supabase dashboard under Settings → API Keys. The new publishable and secret keys are listed there, the old anon and service_role keys under the legacy keys. Supabase plans to retire the old keys by the end of 2026; the exact date is still open. Never copy the secret key into a variable prefixed NEXT_PUBLIC_ or VITE_, because both are compiled into the browser bundle.
How do I check whether Row Level Security is enabled?
In the Supabase dashboard's SQL Editor: select tablename from pg_tables where schemaname = 'public' and rowsecurity = false; lists every table without RLS. Then query pg_policies to see whether a policy only contains “true”, because then anyone may read despite RLS. The dashboard's Security Advisor flags missing RLS as well.
Was there a Lovable data breach?
Three cases are publicly known. In 2025 a researcher found insufficient Row Level Security in 170 of 1,645 scanned Lovable projects (CVE-2025-48757, disputed by Lovable). In February 2026, according to a security researcher, 18,697 user records were retrievable in a single app built on Lovable; Lovable disputes parts of this. And according to Lovable's statement, signed-in users could view chat histories and source code of other users' public projects between 3 February and 20 April 2026; according to Lovable, private projects and Lovable Cloud were not affected.
Is an app built with Lovable GDPR-compliant?
Not automatically. What counts is what you ship: access control on tables holding personal data (Art. 32 GDPR), a complete legal notice, a privacy policy with the mandatory Art. 13 information and no trackers before consent. Plus the DPA with Lovable or Supabase. A scan classifies this technically and does not replace legal advice.
What does the security scan cost?
Nothing. The decivo Scan is free in all three tiers: from the outside, with operator proof and with read-only GitHub access. You only pay if you want help, e.g. the immediate mitigation for €540 net or the repair plan for €349 net.
Related articles
- Vibe Code Rescue
Is Lovable GDPR-Compliant? DPA, Data Location, Duties
Lovable ties its DPA to Business and Enterprise, Lovable Cloud stores data in the chosen region — AI requests not. How Supabase, Base44 and Bolt differ, which obligations your app has itself (legal notice, Art. 13, § 25 TDDDG, AI Act Art. 50, BFSG) a 12-point checklist and our own data from 454 AI-built apps in the DACH region.
- Vibe Code Rescue
Lovable app not working anymore? The honest emergency guide
Your Lovable app breaks on every click and the AI agent makes it worse? Common errors and their causes, what revert and “Try to fix” really do, what to check yourself in 5 minutes and when a rescue beats a rebuild.
- WordPress
WordPress Maintenance 2026: Costs, and When Moving Pays Off
Maintenance contract, plugin licences, hosting: a bilingual Elementor company site calculated with real list prices (around €1,360 to €1,390 a year). With a worksheet to fill in, seven questions for your maintenance contract, a routine for doing maintenance yourself and an honest answer on when to stay on WordPress.
Check whether your app is secure. In minutes.
The free decivo Scan looks for the most common gaps right at your URL and tells you clearly whether you need to act.
Free · no code access needed · result in minutes.