The platform is — it is Postgres with a well-tested API layer in front of it. The exposure in real projects comes from configuration you own: Row Level Security policies, which key ships in the browser, whether storage buckets are public, and whether the auth settings match how your app actually works.

What is the single most common Supabase security problem?

A table readable by anyone, because Row Level Security was never enabled or the policy was written USING (true). It is what CVE-2025-48757 covered, across 303 endpoints in more than 170 apps.

Do I need a backend to be secure with Supabase?

No. Querying the database directly from the browser is the intended design. It just means the database rules are your only enforcement point, so they have to be right rather than merely present.

Guide3 min readUpdated 2026-08-10

Is Supabase secure? What you are responsible for

The platform is not the weak part. The four settings you were never told about are.

Supabase gets blamed for a class of breach it does not cause. The platform is Postgres with a well-tested API layer in front of it. What leaks data is the part that is yours: the browser holds a key and queries the database directly, and the rules deciding what it may reach are rules you write — or, more often, rules an AI wrote quickly so the app would run.

The four things that are actually yours

Row Level Security — which rows each visitor may read and write. This is the one that leaks whole user tables.
Keys — the anon key belongs in your frontend; the service_role key ignores every policy and must never leave your server.
Storage — buckets have their own access settings and a public bucket ignores your table policies entirely.
Auth settings — email confirmation, redirect allow-lists, and where the session is stored in the browser.

Check all four in about five minutes

In order of how much damage each one does

1Query a user table with only your anon key, signed out. Rows coming back means it is public.
2Search your deployed JavaScript for service_role. Any hit is an emergency — rotate before anything else.
3Open Storage in the dashboard and check which buckets are marked public, then open a file URL in a private window.
4In Authentication → Providers, confirm email confirmation is on, and in URL Configuration, confirm redirect URLs are an explicit list rather than a wildcard.

The first two, from a terminal

# 1. can a stranger read your table?
curl "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*&limit=3" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

# 2. which key is in your bundle? (paste it in place of THE_KEY)
echo "THE_KEY" | cut -d. -f2 | base64 -d 2>/dev/null | grep -o '"role":"[^"]*"'

Hand the whole audit to your AI

Paste this into your AI coding tool

Audit my Supabase project's security configuration and report what is
wrong before changing anything.

1. Row Level Security: for every table in the public schema, is RLS
   enabled, and does each policy actually restrict anything? Flag any
   policy whose USING clause is unconditional, and any table covered for
   SELECT but not INSERT, UPDATE and DELETE. Flag policies that trust a
   value the client can edit, such as a role in user metadata.
2. Keys: find every Supabase key in the project, including git history.
   Decode each eyJ token and report its role claim. Say plainly whether any
   service_role or sb_secret_ key is reachable from client code.
3. Storage: list buckets, whether each is public, and what kind of files it
   holds. A public bucket ignores table policies.
4. Auth: is email confirmation required, and are redirect URLs an explicit
   allow-list rather than a wildcard?

Then give me, per finding: the severity, the exact fix, and how I verify it
afterwards from outside the app with curl.

Do NOT disable RLS, do not write USING (true), and do not resolve any error
by switching to the service_role key.

Common questions

Is Supabase secure?: The platform is — it is Postgres with a well-tested API layer in front of it. The exposure in real projects comes from configuration you own: Row Level Security policies, which key ships in the browser, whether storage buckets are public, and whether the auth settings match how your app actually works.
What is the single most common Supabase security problem?: A table readable by anyone, because Row Level Security was never enabled or the policy was written USING (true). It is what CVE-2025-48757 covered, across 303 endpoints in more than 170 apps.
Do I need a backend to be secure with Supabase?: No. Querying the database directly from the browser is the intended design. It just means the database rules are your only enforcement point, so they have to be right rather than merely present.

This is one check out of 40+

Paste your site address and we run the whole list from the outside — leaked keys, open databases, unprotected pages — then hand you one prompt that fixes what we find. Free, about 30 seconds, no signup.

Check my site — free