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.

An INSERT policy with no WITH CHECK clause does not constrain the rows being written, so a caller can insert rows attributed to other users. On UPDATE and ALL, Postgres uses the USING expression as the write check when WITH CHECK is omitted, and that fallback is not itself an ownership bypass. This rule reports an INSERT that omits WITH CHECK, and an UPDATE or ALL policy only when it also has no USING expression to fall back on.

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.