Lovable and Supabase security: what to check before launch.

The short answer.

Which backend you’re on.

Lovable gives you two choices. Both run on Supabase, so the same rules protect your data either way.

The keys, explained.

Supabase uses two kinds of key, and it’s retiring the older names, anon and service_role, by the end of 2026.

Supabase compares the publishable key to a key that only opens the lobby, and the secret key to the master key. Supabase also refuses secret keys sent from a browser, but anyone who copies one can still use it from a script, so a secret key in your app’s code is a leak, whatever else is in place.

How row-level security works.

Row-level security, or RLS, is a set of rules that run inside the database. Each rule works like a filter added to every query. This one lets each signed-in user read only their own orders:

-- Each user can read only their own orders
create policy "Users read their own orders"
on orders for select
to authenticated
using ( (select auth.uid()) = user_id );

In plain terms: when someone reads the orders table, only rows whose user_id matches their own account come back. Supabase checks two things before any row is returned: whether that kind of user may touch the table at all, and then which rows the rules allow. Supabase’s advice is to turn RLS on for every table your app can reach.

Common mistakes.

Five that come up again and again in AI-built apps. Each one looks fine in a demo.

• Row-level security switched off

  Supabase’s docs are blunt: a table without it is readable and writable by any role with access to it. With the public key in your app, that means anyone.

• A rule that lets everyone through

  Security is on, but the policy allows every row to every user. It passes a quick glance and protects nothing.

• Rules for reading, not for changing

  Users can only see their own records, but a separate rule lets them edit or delete anyone’s.

• The secret key used to “fix” an error

  A permission error appears, the AI swaps in the secret key, and the error goes away, because every rule is now skipped.

• File storage left public

  Uploaded IDs, invoices or photos sit in a public bucket, readable by anyone who has or guesses the link.

Check your app in an afternoon.

Eight checks you can do yourself. Tick them off as you go.

When scans aren’t enough.

Run both scanners; they catch the obvious gaps quickly. But Lovable’s own docs say its scans “do not replace a thorough security review”, and suggest a professional review for apps that handle sensitive data.

The reason is simple. A scanner can tell you a table has a rule. It can’t tell you whether the rule matches how your business works: whether a coach should see another coach’s clients, or a team member can delete the owner’s invoices. That takes someone reading the rules against your app.