Supabase security checklist

Most AI app builders put your data in Supabase and let the browser talk to it directly. That is safe only if row level security is right on every table. This is how to check.

Last reviewed 2026-09-30Written by Jacob Masse, TrazTech Inc.

A Supabase-backed app is secure when row level security (RLS) is enabled on every table the API exposes, every policy restricts rows to the right user or organization, the service role key never leaves the server, and storage buckets holding private files are private. The browser holds the project URL and the public anon key by design. Whatever RLS allows, anyone with those two values can do.

Row level security

0 of 0 done · Reset

• RLS is enabled on every table in the public schema
• Every table has explicit policies for select, insert, update and delete as needed
• No write policy is simply true
• Select policies do not return other users' rows
• Policies use auth.uid(), not a user ID sent by the client
• Team data uses a membership check, not a column the user can edit
• Views and functions do not bypass RLS with security definer unless intended

The common ways these go wrong are on Supabase RLS mistakes.

Keys

0 of 0 done · Reset

• The service role key is only in server code or edge function secrets
• It does not appear in the built front end or the repository
• Third-party keys are called from edge functions, not the browser

Storage

0 of 0 done · Reset

• Buckets with private files are private
• Storage policies restrict files to their owner
• Upload size and file type limits are set
• Public buckets hold only files meant to be public

Auth settings

0 of 0 done · Reset

• Email confirmation is required
• Redirect URLs are restricted to your own domains
• Leaked password protection or equivalent is on where available
• Anonymous sign-ins are off unless the product needs them

Edge functions

0 of 0 done · Reset

• Each function verifies the caller's JWT
• Functions check permissions, not just authentication
• Functions do not return more data than the caller needs

How to test it yourself

1. Create two accounts in different organizations.
2. Logged in as the first, open the browser console and query a table with the Supabase client, filtering for the second user's rows.
3. Try an update and a delete on a row you do not own.
4. Log out and repeat with no session.
5. Anything that succeeds is a finding.

Supabase's own security advisor in the dashboard flags tables without RLS. Use it. It cannot tell you whether a policy matches your business rules, which is what a security test checks. This is the failure behind the public vulnerability record CVE-2025-48757 affecting Lovable-generated projects; see Lovable app security.

Common questions