Supabase security checklist for apps built with AI

A Supabase app is protected by two layers. Grants decide whether a role can reach a table at all, and row level security decides which rows it can see. Your keys decide which role a request runs as. Atlas, our example app at atlas.example, uses Supabase for every example below.

Which key can go in the browser?

Supabase says anyone can read the publishable key, so it only reaches what Row Level Security allows. A secret key bypasses every Row Level Security policy, and Supabase says never to put one in a browser, a shipped application or source control. So the publishable key in Atlas's bundle is expected, and the secret key belongs only in server code and Edge Functions.

Is row level security on for every table?

Supabase says a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Turn it on for every table your app reads through the Data API, then add a policy for each thing a person should be able to do.

What changed about new tables?

Supabase stopped automatically exposing new tables in the public schema to the Data API for new projects from May 30, 2026, as a gradual rollout over a few weeks. It applies the same setting to all existing projects on October 30, 2026. After that, a new table needs an explicit grant before the Data API can see it.

What does an outside check prove?

Less than it seems.

Supabase says a missing grant returns a permission error, whereas a policy that matches no rows returns an empty result. With the new default, a refused or empty read can simply mean the table was never granted to the Data API. Neither one proves the table is well protected, so review each table's grants and policies yourself.

How to check

1. Open the Security Advisor in your Supabase dashboard and fix what it flags.
2. Run a quick check on your published address to see what a stranger sees, then read how we check for what it covers.
3. Copy each fix prompt into your builder and review the change.