The Lovable security checklist, starting with the 2-minute Supabase check

Lovable is one of the fastest ways there is to go from an idea to a working app, and if you shipped something with it, that speed worked in your favor. This checklist is about the part Lovable does not do for you: making sure the app it generated actually protects your users' data. It is shorter than you might expect. Lovable apps share one architecture, Supabase underneath a generated frontend, so they share one list of things to check, and the most important one takes about two minutes.

Start there. Everything else on this list can wait until this first check is done.

The big one: your database may be publicly readable

Lovable apps talk to a Supabase database, and the browser connects to it using a public key that ships with your app. That is by design, and it is fine, because Supabase has a feature called Row Level Security (RLS) that decides which rows each user is allowed to see. Here is the catch: RLS is a per-table setting, and a table without it will answer anyone who asks, whether or not they are logged in. Your app's own pages will look completely normal either way. The difference only shows up when someone queries the database directly, which anyone can do, because the key is public.

This is the pattern behind CVE-2025-48757, where researchers found 170+ Lovable-built apps exposing user data, including emails and payment details, to anyone who queried them. Those apps all worked. Their owners had no way to notice from inside the product. That is why this check is worth two minutes even if, and especially if, everything seems fine.

The 2-minute check

1. Open your project in the Supabase dashboard.
2. Go to the Table Editor.
3. Look at each table in the left sidebar. Supabase shows an "RLS disabled" warning badge on any table that has Row Level Security turned off.
4. Count the warnings. Zero warnings: you are in good shape, skip to the next section. One or more: those tables are the ones to fix, and the prompt below does it.

That is the whole check. If you saw warnings, do not feel bad about it; Lovable generated the tables and simply did not always generate the rules, particularly in projects created before mid-2025. Make sure it's actually done now, and this stops being your problem.

The fix, verbatim

Paste this into your Lovable chat exactly as written. It has Lovable enable RLS everywhere, write sensible policies, and report back in plain English:

Review my Supabase database security. For every table in the project:

1. Check whether Row Level Security (RLS) is enabled. Enable it on every table where it is off.
2. Write RLS policies so that users can only read and write their own rows. Use auth.uid() to match rows to the logged-in user.
3. If a table is meant to be publicly readable (for example, a list of published posts), say so explicitly and write a read-only policy for it instead of leaving RLS off.
4. List every table you changed and what its policies now allow, in plain English.
5. Tell me how to verify each policy in the Supabase dashboard when you are done.

Do not weaken or delete any existing policies without telling me.

When it finishes, go back to the Table Editor and confirm the warnings are gone. Then click into a table's policies and read what they say; they are short, and Lovable's plain-English summary should match. Verification is your half of the job, and it is the easy half.

Leaked keys: one is fine, one is not

Supabase gives your project two main keys, and telling them apart resolves most of the confusion about Lovable security:

• The anon key ships in your app and is visible to anyone who opens browser developer tools. That is normal and by design. RLS is what limits what it can do, which is why the section above comes first.
• The service_role key bypasses RLS entirely. It belongs in server-side code and environment variables only. If it appears anywhere the browser can load, treat it as exposed and rotate it in your Supabase dashboard now.

Beyond the Supabase pair, check for any other keys the AI hardcoded along the way: payment providers, email services, AI APIs. Keys in code end up in git history, and git history gets scraped at scale. In February 2026, researchers at Wiz found an exposed database revealing roughly 1.5 million API keys. The lesson for your app is simple: any key that ever appeared in code gets rotated, not just deleted. The full vibe coding security checklist has a copy-paste prompt for the cleanup.

Auth settings worth two minutes each

• Email confirmation. If any part of your app assumes a user's email is real, confirm "Confirm email" is enabled in Supabase Auth settings. Otherwise anyone can sign up as anyone.
• Redirect URLs. The allowed redirect list in Auth settings should contain only URLs you own. A stray wildcard here lets login links deliver users, and their tokens, somewhere else.
• Protected pages, enforced server-side. Log out and visit your private and admin URLs directly. If a page's data is protected only by the frontend hiding a link, the data is not protected. With RLS in place, even a visitor who reaches the page gets an empty response, which is the behavior you want.

If a table was open: what to do beyond the fix

If the 2-minute check found tables with RLS off, fixing them forward is the first half. The second half is being honest with yourself about the past:

• Rotate anything an open table could have revealed. If an exposed table held API keys or tokens, rotate those at their providers, the same as if they had been committed to code.
• Check your logs. Supabase keeps API logs in the dashboard. Unusual query volume or queries against tables your app never touches directly are worth a look. Absence of anything odd is not proof, but it is information.
• If sensitive user data sat open, tell your users. It is an uncomfortable email to write and the right one to send. The builders affected by CVE-2025-48757 did not do anything unusual; they used a popular tool that had a gap. What you control is what happens after you find out.

What a scanner can't catch

A scan of your repo can find hardcoded keys, flag missing security patterns, and catch risky dependencies. Honesty about the rest:

• Your RLS policies' intent. A scan can notice code that assumes RLS, but only you know whether "users can see all published posts" is a feature or a leak. Reading your policies in the dashboard takes minutes and is worth it.
• Data that already left. If a table sat open for months, no tool can tell you whether anyone queried it. Fix the tables, rotate the keys, and if you handled sensitive user data, be straight with your users about it.
• Settings that live outside the repo. Auth configuration and dashboard settings are not in your code, so the two-minute checks above are yours to do.

Frequently asked questions

Is Lovable safe to use?

Lovable itself is a legitimate, widely used platform, and it has improved what it generates. The honest answer is that safety lives in your app, not the tool: Lovable apps sit on Supabase, and the security of your data comes down to whether Row Level Security is configured on your tables. That is checkable in minutes, which is what this guide is for.

Didn't Lovable already fix the Row Level Security problem?

Lovable updated its generation pipeline after CVE-2025-48757 so new projects include RLS policies more consistently. Apps generated before that, and tables added by later AI edits, are not automatically covered. If you have not personally seen RLS enabled on every table in your dashboard, run the 2-minute check.

My Supabase anon key is visible in the browser. Is that a leak?

No, that part is by design. The anon key is meant to be public, and Row Level Security is the mechanism that decides what it can actually reach. A visible anon key with RLS enabled on every table is normal. A visible anon key with RLS disabled is the problem pattern. The service_role key is different: it bypasses RLS and must never appear in browser code.

Do I need to learn SQL to fix my RLS policies?

No. Lovable can write the policies for you: paste the fix prompt from this guide into the Lovable chat and it will enable RLS and generate policies for your tables. Your job is verification, which happens in the Supabase dashboard and needs no SQL.

I built my app months ago and it works fine. Does this still apply?

Yes, and arguably more. "Works fine" and "publicly readable" look identical from inside the app; the affected apps in the CVE-2025-48757 research all worked fine. Older apps predate Lovable's generation improvements, so the check matters most for exactly your case.

Once the Supabase side is handled, the rest of your app deserves the same pass: the complete security checklist for vibe-coded apps covers input handling, dependencies, and rate limits, and if your project lives on GitHub, here is how to scan the whole repo in one pass.