Does Lovable's Security Feature Actually Work? We Tested It

Lovable has a built-in security feature you can toggle on for your app. The pitch is simple: turn it on, get a more secure app. But does it actually close real security holes, or just for show?

I wanted an actual answer instead of a guess, so I tested it with BattleTester, an automatic penetration testing tool I built over the past year. BattleTester crawls your app like a real user, signs in under different roles (guest, regular user, admin), and tests what each role can actually reach, then verifies every finding with AI so you're not stuck chasing false positives.

How I tested it

• Built a books-selling site in Lovable
• Ran a full BattleTester scan against it
• Toggled Lovable's security feature on
• Ran the exact same scan again

Every finding was checked by hand afterward. One issue from the first scan turned out to be a false positive, a request that looked like it succeeded but didn't actually change anything.

The results

Before toggling security on: 16 issues, 6 of them critical. Profiles, orders, support chats, even who's an admin, were all readable and editable by people who shouldn't have had access.

After toggling security on: 12 issues, 2 of them critical. Better, but not close to fixed. Some of that drop is BattleTester scoring the same underlying bugs lower, not the bugs actually being resolved.

What "editable" actually means here

Lovable apps run on Supabase underneath, and Lovable's security toggle is really just turning on Supabase's row-level security (RLS), the database-level rules that decide who's allowed to read or write which rows. When RLS isn't locked down correctly, it's the difference between a stranger changing your store's shipping settings, or reading another customer's order and address, without ever being an admin. It's not a theoretical bug, it's data belonging to real people sitting behind a door that isn't actually locked.

Guest vs logged-in user

The toggle did change something specific: before, a stranger with no account at all could reach some of these issues. After turning security on, that path closed. You now need to create an account first.

The problem is that signing up takes about ten seconds and nobody verifies who you are. Once you're a regular logged-in user, not even an admin, you could still edit the store's global settings and pull other customers' orders and personal info.

Conclusion

The security feature did help, just not by much. A guest can no longer wreck your system, but a logged-in user still can, and getting a logged-in account costs nothing but ten seconds.

It feels like Lovable locked the front door and left a window open. The real risk with a feature like this is the false sense of security it gives you, you turn it on, see fewer issues, and assume you're covered.

How to check if your own Lovable app has this issue

If you're running a Lovable app, or anything built with an AI coding tool, the fastest way to check is to ask: what can a logged-in user reach that they shouldn't be able to? Not an admin, just a regular signed-up account. Can they see or edit anyone else's data, or change settings that should be admin-only?

If you don't know the answer, that's exactly the gap BattleTester is built to find. The free surface scan will crawl your app and give you a first read in a few minutes.

Edit: BattleTester also gives step-by-step AI-written fix instructions for each issue. I handed those to Lovable and it fixed every single one.