Three Supabase RLS settings worth checking before launch

Nightshift Scan — Wed, 21 Oct 2026 13:00:00 +0000

Three database settings are worth checking in a Supabase project. Here is what each one means and a read-only query to find it.

1. Tables with RLS disabled

Anyone with your project's public anon (or publishable) key (it ships in your frontend) may be able to read or change them through the API, depending on your grants.

select n.nspname as schema, c.relname as table_name

from pg_class c join pg_namespace n on n.oid = c.relnamespace

where n.nspname = 'public' and c.relkind in ('r','p') and not c.relrowsecurity;

Policies with `using (true)`

Fine for public data, risky for per-user rows.

select schemaname, tablename, policyname, cmd

from pg_policies

where schemaname = 'public' and permissive = 'PERMISSIVE'

  and (qual = 'true' or with_check = 'true');

Views without `security_invoker = true`

They run with the owner's rights and may bypass RLS on the underlying tables.

select n.nspname as schema, c.relname as view_name

from pg_class c join pg_namespace n on n.oid = c.relnamespace

where n.nspname = 'public' and c.relkind = 'v'

  and not exists (select 1 from unnest(coalesce(c.reloptions, '{}'::text[])) o

                  where lower(o) in ('security_invoker=true','security_invoker=on',

                                    'security_invoker=yes','security_invoker=1'));

How to read the output

Each row is something to review, not a verdict. A using (true) policy on a public lookup table can be intended. On a table holding per-user rows, it usually isn't what you want. Also review policies like auth.uid() is not null or auth.role() = 'authenticated': they let every logged-in user read every row, and this check doesn't flag them. For views, alter view ... set (security_invoker = true); makes them respect the caller's RLS (Postgres 15+).

Limits

These are read-only catalog checks only. They don't test your live app, API, Edge Functions or storage, and a clean result doesn't show there are no issues. Only the public schema is checked; other schemas you expose through the API aren't. Materialized views aren't covered by these three queries (RLS doesn't apply to them); the full script lists them. Supabase's own Security Advisor already flags RLS-disabled tables and security-definer views; these queries are a companion to it, not a replacement. Run them only on a database you own or are authorised to access.

Why it matters

UpGuard research found 16,326 Supabase databases with tables readable from the public internet, among about 300,000 domains showing signs of Supabase use. Over half had signs of personal data in their table structure. UpGuard attributes it mainly to project configuration, such as missing or overly broad row-level security. Source: UpGuard, "Everything Everywhere: Systemic Data Exposure in Supabase Apps" (upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps).

Full script, these three checks plus one for materialized views in a single read-only SELECT: https://github.com/nightshiftscan/supabase-rls-self-check (Apache-2.0)

More: nightshiftscan.com

Nightshift Scan · hello@nightshiftscan.com · Legal notice: https://nightshiftscan.com/privacy#legal-notice

DEV Community: Nightshift Scan