---
title: "Lovable apps, RLS, keys, and auth"
slug: lovable-rls-keys-and-auth
severity: critical
category: Database
summary: "Lovable's own Supabase guide says missing row level security policies are the most common way app data gets exposed, and that secret keys must stay out of the client."
platforms:
  - Supabase
updated: "2026-10-14"
related:
  - supabase-tables-without-rls
  - secret-keys-in-the-frontend
  - auth-checked-only-in-the-ui
---

Lovable's Supabase integration doc says the built-in backend uses Supabase's database, auth, storage, and edge functions, and that you can also connect your own Supabase project. The same page says Lovable checks Row Level Security coverage after schema changes, and that missing RLS policies are the most common way app data gets exposed.

Sign-in on that page is Supabase Auth: email and password, social login, and access control. A screen that hides a button is not that control. Supabase's securing-data guide says the publishable key is safe to put in the client only when RLS and grants are in place, and that a secret key bypasses RLS and must not be exposed.

## How to check in 5 minutes

1. In Lovable, open the database view and the Supabase dashboard. For each public table, confirm RLS is enabled and the policy names who can read and write a row. Lovable's doc says to verify this yourself, not only to trust the automated check.
2. Search the project for `VITE_` and for `SERVICE_ROLE`. Lovable's secrets doc says `VITE_` values are embedded in the client bundle, and that `SUPABASE_SERVICE_ROLE_KEY` is injected into Edge Functions. It must not appear in frontend code.
3. Sign out and request a row you should not see, using the publishable key the client already has. An empty result or a permission error is the pass. A row of someone else's data is the failure Supabase documents when RLS is off or the policy is open.

## How to fix

### Lovable

Ask Lovable to restrict each table to the signed-in user, then open the Supabase dashboard and read the policy. Lovable's integration doc gives the example prompt "Make sure users can only see and edit their own data." Put private keys in Secrets, not in `.env` under a `VITE_` name. Lovable rejects a `VITE_` name in Secrets and says those values belong in `.env` because they are browser-exposed.

### Supabase

Enable RLS and add policies for `anon` and `authenticated`. Supabase's API key guide says policies never apply to a secret key, because `service_role` has `BYPASSRLS`. Keep that key in the Edge Function environment Lovable already populates. Do not prefix it with `VITE_`.

## Agent prompt

```text
You are fixing data access in a Lovable project. Do not add features.

1. List tables exposed to the client. Enable RLS and replace any policy that lets every caller read or write every row.
2. Search for VITE_ variables and for SERVICE_ROLE. Leave only publishable values in VITE_. Move secret keys into Lovable Secrets or Supabase edge-function secrets.
3. Show me the policy SQL and the file where the browser client is created. Do not claim the app is safe.
```

## FAQ

### Does Lovable's publish scan replace reading the policies?

No. The security page says a basic scan runs on publish and checks RLS, in about 10 to 15 seconds. The Supabase integration doc still says to verify policies in the dashboard. A deep scan is a separate on-demand pass of about 3 minutes.

### Are Lovable secrets copied when someone remixes the project?

Lovable's secrets doc says manually added secrets are not copied into a remix. Lovable-generated keys are recreated. A remixed app will not have your Stripe or model key unless someone pastes it again.

## Sources

- [Connect to Supabase](https://docs.lovable.dev/integrations/supabase)
- [Lovable secrets](https://docs.lovable.dev/features/secrets)
- [Security at Lovable](https://lovable.dev/security)
- [Securing your data](https://supabase.com/docs/guides/database/secure-data)