Lovable App Security: A Real App, 29 Issues Found

Quick answer: Lovable app security's most common failure isn't a missing header — it's an unset Supabase Row-Level Security policy. Skip it and the app still works, because the query still succeeds, just for anyone, not only its owner. We scanned a real Lovable app and found exactly that gap, live.

Jump to: the scorecard, what it got right, what was hiding underneath, why this is the default, what to actually do about it, and a quick FAQ at the end.

Picture the app you shipped last sprint. You described a dashboard, Lovable wired up the tables, the auth, the UI, and it all just worked the first time you clicked through it. That's the whole appeal. It's also exactly why nobody goes back and checks the one setting that doesn't announce itself when it's missing. So we did. We took a real, live Lovable app, built the way most Lovable apps get built (fast, from a prompt, shipped the same week), and ran it through FlawPilot, our free scan that checks a site's security, performance, infrastructure, and SEO in about two minutes, no login required. We won't name the app, but every number below is real, pulled straight from its report.

The Lovable app security scorecard

63 out of 100. "At risk." 252 points out of a possible 400, and 29 things sitting open: 1 critical, 5 high, 15 medium, 8 low.

Split out, it reads like this:

• Security: 55/100. At risk. 13 findings.
• Performance: 96/100. Excellent. 2 findings.
• Infrastructure: 58/100. At risk. 9 findings.
• SEO & Discoverability: 62/100. Needs attention. 5 findings.

Nothing was defaced. The app looked, and behaved, exactly like it was supposed to. That's the part worth sitting with: every screen worked, every click did the right thing, and the one critical finding on this report had never once shown up as a bug.

Let's start with what it got right

96 out of 100 on performance is close to a clean sweep. Lovable's scaffolding leans on Vite and React defaults that are already fast out of the box, and it shows: quick first paint, sensible bundle size, nothing render-blocking that shouldn't be. Whatever else is true about this app, nobody was going to complain that it felt slow.

Which is exactly the trap. A fast, polished frontend is the thing you notice with your own eyes, so it's the thing that gets credited as "done." Everything below is the kind of gap that only shows up once something outside the team, a scanner, a bot, or a person who isn't supposed to, goes looking for it on purpose.

The Lovable security issues we found

Here's what "somebody went looking" turned up, worst first.

A Supabase table had no Row-Level Security policy at all. Rated Critical, and it's the finding that matters most on this whole report. Lovable apps run on Supabase by default, and Supabase enforces access at the database layer through RLS policies, not through the app's own login screen. Turn RLS on for a table and the database itself checks who's allowed to see which row. Leave it off, and the table is exactly as open as the anon key that ships in every Lovable app's JS bundle, which is to say: open to anyone who opens dev tools and watches a single network request. This app's login screen worked correctly the whole time. The database behind it never checked whether the person asking was allowed to see the data they were asking for.

Anyone could send an email pretending to be this company. High, and the reason is small: there's no DMARC record on the domain, so mail servers have no way to verify whether an email claiming to be from the company actually is. A spoofed phishing email using their own domain would sail straight through.

No Content-Security-Policy header. Also High. A CSP is the fence that stops an injected script from running loose in a visitor's browser. This app didn't have one.

No Strict-Transport-Security header. A visitor's first request could get quietly downgraded to plain HTTP before HTTPS ever takes over, readable and alterable in that window. High.

No clickjacking protection. The app could be loaded invisibly inside someone else's page and used to trick visitors into clicking things they never meant to click.

Underneath those sat a run of Mediums that all point the same direction: DNS and email configuration nobody had circled back to, the infrastructure side of the report that's easy to forget exists once the app itself is live. No CAA record, so any certificate authority could issue a cert for the domain. No DKIM signature, putting outgoing mail at real risk of landing in spam. A missing sitemap.xml and thin meta descriptions dragged the SEO score to 62. And a verbose error page, still left on, was handing back stack traces to anyone who managed to trigger one.

None of this showed up while clicking through the app. All of it shows up the moment something outside the team bothers to check.

Why Lovable security gaps are the default, not a fluke

That combination, an unset RLS policy sitting next to missing headers and no DMARC, is close to the single most repeated pattern we see across Lovable apps specifically. It's not that Lovable is careless. It's that Lovable is optimizing for "the prompt works," and a Supabase table without an RLS policy still returns exactly the data you asked for in testing. The query succeeds either way. Nothing about that failure looks like a failure until someone sends a request the app wasn't expecting.

This isn't a hypothetical risk unique to the app we scanned. In March 2025, this exact gap, a missing Row-Level Security policy in Lovable-generated apps, was catalogued as CVE-2025-48757, CVSS 9.3, and it left more than 170 live production apps with databases that any unauthenticated visitor could read, write to, or delete from, just by inspecting the app's own network requests. Nobody wrote a bug that broke anything. The gap was a security control nobody had reason to think about, sitting quietly under apps that worked perfectly for months.

The research on AI-generated code backs up why this keeps happening. Veracode's 2025 GenAI Code Security Report tested over 100 large language models across 80 coding tasks and found that AI-generated code introduced exploitable security flaws in 45% of tests, with no improvement as the models got better at writing functional code. A 2023 Stanford study (Perry et al., ACM CCS) found the same pattern at the human level: developers using an AI coding assistant wrote measurably less secure code than developers working without one, and felt more confident about it, not less. The role that used to catch an unset RLS policy, a senior engineer flagging it in review, mostly doesn't exist in a Lovable workflow, because there's often no review step between describing the app and the app going live. Nobody removed that safety net on purpose. It's just gone, and a scan is what fills the gap it left.

How to fix Lovable security issues

A severity label is only useful if it turns into something you actually do. So here's how FlawPilot handles that, on this exact report.

Every finding gets grouped by area and dropped into a "What to do next" list, ranked by what actually matters, not a raw dump of jargon. Item one on this report was the RLS finding, and right next to it, in plain English: enable Row-Level Security on this table and add a policy scoping rows to the authenticated user. Nothing to look up. Nothing to decode.

That's the whole idea. Most security tools stop at "here's what's broken" and leave you to figure out the rest. FlawPilot's free report hands you the fix for the top issue in every area, spelled out, at no cost. Past that (and for a full crawl of the site instead of a handful of representative pages), Logicwind's team builds the prioritized remediation roadmap and puts engineers on it directly, including the Supabase policy work itself if that's where the help is needed. Finding the gap and fixing the gap don't have to be two separate projects with two separate vendors.

And the part worth an afternoon of your time: four of the five High findings here (CSP, HSTS, clickjacking, DMARC) are pure configuration, no application logic involved. The RLS fix is a Supabase policy, not a rewrite. Clear those five and close out the CAA and DKIM gaps sitting next to them, and a security score that opened at 55 is realistically headed for the 90s (illustrative, since the exact number depends on what else the fix touches), but the direction isn't in question.

Check your Lovable app's security score, free

You don't need a security background to read a report like this one, or to know whether your own Supabase tables have RLS turned on. You need to run the scan.

No setup, no coding, no passwords required. Drop in a URL, and in about two minutes you get the same kind of scorecard back: security, performance, infrastructure, and SEO, each out of 100, every finding in plain English, with a toggle between the founder view and the full technical one.

Your app already works. The only question left is whether it's been checked, or just assumed.

Scan your Lovable app for free →

Is Lovable secure by default?

Not fully, and the honest gap is specific: Lovable handles HTTPS and gets you a working auth flow fast, but Row-Level Security on your Supabase tables is opt-in, and HTTP security headers, DMARC, and DNS hardening aren't configured automatically either. Lovable app security mostly comes down to whether someone went back and turned those on.

What's the single most common Lovable security issue?

A Supabase table with no Row-Level Security policy. It's also the most severe, because it doesn't just leave a header missing, it can leave the underlying data readable or writable by anyone, exactly the pattern behind CVE-2025-48757.

What is CVE-2025-48757, and does it affect my app?

It's a March 2025 vulnerability catalogued at CVSS 9.3, describing Lovable-generated apps left without Row-Level Security policies, which exposed over 170 production databases to unauthenticated read and write access. If your app has any Supabase table without an explicit RLS policy, the same pattern applies to you regardless of whether it has a CVE number attached.

Does scanning my site mean giving FlawPilot access to my Supabase project?

No. The scan only checks publicly accessible signals, the same things any browser or bot on the internet can already see. It never touches your Supabase dashboard, your database directly, or your credentials.

Can I fix this myself without hiring a developer?

Header, DNS, and email-authentication fixes usually live in your platform or DNS provider's dashboard. The RLS fix lives in your Supabase project's policy editor and takes minutes once you know which table needs it, which is exactly what the report tells you.

How often should I actually check this?

Before anything you'd call a real release, and again any time you add a new table. A new feature often means a new table, and a new table means RLS is opt-in again.

How do I run this on my own app?

Head to flawpilot.com and drop in your URL. No login, no setup. Two minutes later you've got a full scorecard. Scan now, free →

This is the third post in our series on what AI coding tools leave unconfigured by default. The first one walked through a real scan end to end. The second one covered Cursor specifically. This one's about Lovable, and the pattern holds: the app works, the security step just isn't anyone's job until you make it someone's job.