If you built your app with Lovable, Bolt, or a similar tool, there's a good chance your data lives in Supabase. You may never have opened it. This guide explains the one setting that matters most, and how to check it in a few minutes.
What Supabase does for your app
Supabase is the database behind your app. It's where your users, their profiles, their orders, and everything else gets saved. Your app talks to Supabase directly from the visitor's browser, using a public key.
That public key is fine to share. It's like the address of a building. What keeps people out of rooms they shouldn't enter is the lock on each door.
The lock: Row Level Security
Supabase calls this lock Row Level Security, or RLS. Each table (think: one spreadsheet, like "users" or "orders") has its own lock.
- RLS off: anyone who knows your app's address can read, change, or delete everything in that table. Your app's public key is enough.
- RLS on, with no rules: nobody can read the table through the app. It's safe, but your app may stop showing data.
- RLS on, with rules (called policies): people can only see what the rules allow, such as "users can see only their own orders."
The goal is the third one, for every table.
How to check your tables
- Log in to supabase.com and open your project.
- Click Table Editor in the left menu.
- Look at the list of tables. A red Unrestricted label means RLS is off for that table, and the data is open to anyone.
- Click Advisors, then Security Advisor. It lists security problems in your project. Anything marked as an error deserves attention before launch.
How to fix an open table
You can ask your builder tool to do it. Be specific:
Turn on Row Level Security for the `orders` table. Add policies so signed-in users can only read and change their own rows. Visitors who aren't signed in should not be able to read it.Swap in your own table name, and describe who should see what. For a table that really should be public, like a list of blog posts, say so: "Anyone can read this table, but only I can add or change rows."
After the fix, check the Table Editor again. The Unrestricted label should be gone. Then test your app to make sure it still works.
The one key you must keep secret
Supabase gives your project two kinds of keys:
- The anon or publishable key: meant for your app. Safe to be public, as long as RLS is on.
- The service role or secret key: skips every lock. It's for your own server code only.
If the secret key is ever in your app's public code, anyone can use it to read and delete your whole database, RLS or not. If you think it was exposed, go to your project's API key settings in Supabase, create a new secret key, and turn off the old one.
Test it like a stranger
Settings only tell you so much. Do one real test:
- Sign up for your app with one email and add some data.
- In a private browser window, sign up with a second email.
- Try to see the first account's data.
If you can't, your locks are doing their job.
Quick checklist
- Every table has RLS turned on (no Unrestricted labels)
- Every table that holds personal info has policies like "users see only their own rows"
- The Security Advisor shows no errors
- The secret or service role key isn't in your app's code
- A second account can't see the first account's data