Is my Lovable app secure? Seven checks you can do yourself

01

Start with Lovable’s own Security view

Open your project and go to More → Security. Lovable has two scans there. The Quick scan already runs every time you publish and looks at your database rules (tables without per-record access control, rules that let everyone through, leaked-password protection turned off), your npm dependencies, and any MCP server your app exposes without sign-in. The Deep scan reads your whole codebase for things like users reaching data that is not theirs, endpoints anyone can trigger, and leaked secrets. Lovable’s docs say running either scan is free.

Run the Deep scan, then read every Critical finding slowly before you click a fix. If one says leaked-password protection is off and your app has email sign-in, turn it on. On Cloud it lives in More → Cloud → Users → Auth settings → Email.

One caution from history. When Palmer wrote up the CVE, he noted that Lovable’s publish check would tell you whether RLS was enabled “but doesn’t necessarily indicate if they are sufficient.” The scans have grown a lot since then. Still, a scanner can see that a rule exists. It cannot know that your orders table should only ever show a customer their own orders. That part is yours, and it is what checks 4 and 5 are for.

02

See which key your page sends

Open your live app in Chrome, open DevTools, and go to the Network panel. Reload the page and use the app for a moment so it loads some data. In the filter box type rest/v1. Click one of the requests, and under Headers find the request header called apikey.

• It starts with sb_publishable_: that is the public key. Good.
• It starts with sb_secret_: that is a secret key. Supabase says secret keys are refused when they come from a browser, so your app is probably half broken already, but the key itself is now public. Go to the fix below.
• It starts with eyJ: it is one of the older keys, and you need to know which. A JWT’s middle part is Base64-URL encoded JSON, and Supabase’s JWT docs explain that its role claim names the database role it acts as. Run this in the same DevTools window, in the Console tab:

// Paste into the Console of your own browser. The key never leaves your machine.
const key = "PASTE_THE_KEY_HERE";
JSON.parse(atob(key.split(".")[1].replace(/-/g, "+").replace(/_/g, "/"))).role;
// "anon" is the public key. "service_role" means stop and read on.

Please decode it in your own console rather than pasting it into a website. If it ever turns out to be the secret one, you don’t want it in anyone else’s logs.

If you find a secret or service_role key in the page, fix the code first, then rotate the key. Ask Lovable to move whatever needs it into an Edge Function, and follow Supabase’s steps for a leaked key. Supabase also says it is deprecating the old anon and service_role keys by the end of 2026, so if your app still uses eyJ keys, moving to publishable and secret keys is worth putting on the list.

03

Search your page for other secrets

The Supabase key is not the only thing that can end up in the browser. Among the 400 or so secrets Escape found were GitHub tokens, OpenAI keys, and payment API keys. Lovable’s Secrets page draws the line clearly. Anything whose name starts with VITE_ is embedded into the code your visitors download. VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY are fine to be public. Things like STRIPE_SECRET_KEY or OPENAI_API_KEY belong in Secrets, where Edge Functions can read them and the browser never sees them. Vite’s own docs say the same about its prefix: VITE_ variables should not contain sensitive information such as API keys.

To look for yourself, open DevTools on your live app and press Ctrl+Shift+F (Cmd+Option+F on a Mac). That opens the Search panel, which searches every file the page loaded. Try each of these in turn:

sb_secret_
service_role
sk_live_
secret

Add the name of every service you have given a key to: Stripe, OpenAI, Resend, Google Maps, whatever you connected. A match is not automatically a leak. The word secret shows up in lots of harmless code. Click each result and read the line around it. If you see something that looks like a real key, treat it as public now. Revoke it at the service that issued it, make a new one, and ask Lovable to keep it in Secrets and call that service from an Edge Function.

04

Ask your tables for data as a stranger

This is the big one: the check behind the CVE, and behind the main cause Escape reported. Copy your project URL and the public key from check 2, open a terminal, and ask for one row the way any visitor to your site could:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=1" \
  -H "apikey: YOUR_PUBLIC_KEY"

Do it for every table that holds anything about your users: profiles, orders, messages, invoices. Real rows from a table that should be private means anyone on the internet can read it right now. An empty list [] means the rules filtered everything out, or the table is empty. A permission error is also fine, if that is what you meant.

Then read the rules themselves.

Last, make two test accounts. Sign in as the second and try to open something that belongs to the first, for example by putting the first account’s record ID in the URL. You should see nothing of theirs. This is the test that catches a rule that is on but too loose, and no scanner can do it for you because only you know whose data is whose.

If you would rather have Lovable do the first pass, its best practices page suggests a prompt you can paste as is: “Review RLS policies to ensure users can only access their own data and shared data is properly protected.” Then test again yourself. For the reasoning behind each rule and SQL to fix them, the Supabase RLS checklist goes table by table.

05

Make your Edge Functions ask who is calling

When something can’t run in the browser, like taking a payment or calling an AI model, Lovable writes an Edge Function for it. Lovable’s security best practices make two points worth reading twice. A function running on the server can still be called directly, without going through your app, so being on the server doesn’t make it private. And code that uses the service role bypasses row level security, so that code has to check permissions itself.

Supabase’s own Edge Function docs carry the same warning in stronger words: a function that reads a shared table with the admin client and doesn’t filter by the caller’s ID “returns every user’s rows.”

Here is how to look without reading much code.

• Open the code editor in Lovable and look for a file called supabase/config.toml. Supabase’s function configuration docs explain that a block like the one below lets anyone call that function without a valid token. That is right for a Stripe webhook, which should check Stripe’s signature instead. It is wrong for anything that acts on behalf of a user.

# supabase/config.toml: each block like this turns off the sign-in check
[functions.stripe-webhook]
verify_jwt = false

• The sign-in check that is on by default is not the whole answer either. Supabase notes that passing it doesn’t on its own prove who the caller is, so a function that does something for a user should look up the signed-in user first and refuse if there isn’t one. Lovable’s docs show exactly that pattern, returning 401 Unauthorized when no user comes back.
• Then test it as a stranger. On Cloud, More → Cloud → Edge functions lists every function and has a Copy URL button. With your own Supabase, the URL is in the dashboard under Edge Functions. Call it with only the public key, the way someone who copied it from your page would:

curl -i -X POST "https://YOUR-PROJECT.supabase.co/functions/v1/YOUR-FUNCTION" \
  -H "apikey: YOUR_PUBLIC_KEY" \
  -H "Authorization: Bearer YOUR_PUBLIC_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

A function that should only work for signed-in users ought to answer with a 401 or a similar refusal. If it happily sends an email, returns data, or spends your AI credits, ask Lovable to add a check that the caller is signed in and allowed to do this, and test again. The Deep scan from check 1 also looks for “functions and routes that anyone can trigger”, so compare notes.

06

Look at your storage buckets

Uploaded files live in buckets, and a bucket is either private or public. Lovable’s storage docs put the difference simply: private files are reachable only by users the rules allow, while public files are “accessible by anyone with the URL.” That is right for product photos and avatars. It is wrong for invoices, contracts, or ID scans.

select id, name, public from storage.buckets;

For private buckets, access comes from rules too. On Cloud, the RLS policies view has a Storage filter. With your own Supabase, step 8 of our RLS checklist has a policy that keeps each user inside their own folder.

07

Read your response headers

This one matters less than the database, and a missing header won’t leak your users’ data by itself. It is still worth five minutes. In the Network panel, reload, click the very first row (your page itself), and read the Response Headers. Look for:

• Content-Security-Policy. MDN describes it as a set of instructions telling the browser what your page’s code may load and do, used mainly as a defence against cross-site scripting, where someone else’s script runs inside your app and sees what your users see.
• Strict-Transport-Security, which tells browsers to stick to HTTPS for your site.
• Either X-Frame-Options or a CSP that includes frame-ancestors. Without one, another site can load yours in a hidden frame and trick people into clicking. MDN suggests frame-ancestors 'none' unless you need your site to be embeddable.

If they are missing, ask Lovable how to add them for your project, then check this panel again. We couldn’t find custom response headers covered in Lovable’s hosting docs, so verify rather than assume. Older Lovable projects are client-rendered React and Vite apps (newer ones use TanStack Start), and for client-rendered apps MDN notes a CSP can also be set with a <meta http-equiv="Content-Security-Policy"> tag, though that route doesn’t support every feature. A strict policy can break things, so MDN’s advice to start with Content-Security-Policy-Report-Only, which reports problems without blocking anything, is a kind one.