Detection rules

Any table reachable through PostgREST with RLS disabled is world-readable to anyone holding the anon key — which ships in your client bundle and is public by design. Every row is exposed.

With RLS on and zero policies, Postgres denies every row to non-owner roles. Data is safe but the table is functionally unreachable from the client, which usually means the setup was left half-finished.

A permissive policy whose expression is a constant true grants the whole table to every role it targets. RLS is enabled, so the dashboard reports the table as protected while it is wide open.

INSERT and UPDATE policies need a WITH CHECK clause to constrain the rows being written. Without one an attacker can write rows attributed to other users, even when reads are correctly restricted.

RLS predicates run on every candidate row. When the predicate column has no index, each query degrades into a sequential scan — the single most common cause of Supabase bills growing faster than traffic.

Objects in a public bucket are served to anyone with the URL, with no auth check. Object paths are frequently guessable, so "public" means "published" for anything stored there.

A bare auth.uid() inside a policy is re-evaluated once per candidate row. Wrapping it as (SELECT auth.uid()) lets the planner hoist it into an InitPlan evaluated once per statement — routinely a 10-100x speedup on large tables, with identical semantics.

The service_role key bypasses RLS entirely. Once it is in a client bundle it is public, and every policy in the project is decorative. Rotate the key immediately and move the calls that need it behind a server route.

This table returned rows to an unauthenticated request carrying only the public anon key. Anything visible here is visible to the internet.