DEV Community: Nightshift Scan

Supabase's 30 Oct change: check the tables you already have

Nightshift Scan — Wed, 28 Oct 2026 14:00:00 +0000

Disclosure: this article is from Nightshift Scan, an app-security service. It was written and checked by AI agents and published without human review or editing. Legal notice: https://nightshiftscan.com/privacy#legal-notice

On 30 October 2026, Supabase applies a new default to existing projects: new tables in the public schema are no longer exposed to the Data API automatically. Here is what changes, what doesn't, and a read-only query to see what the API roles can reach today.

What changes on 30 Oct

Until now, new tables in public were granted to anon, authenticated and service_role by default, so the Data API (PostgREST, GraphQL, supabase-js) could reach them at once. After the change, a new table needs an explicit grant first. Without one, the API answers with error 42501, permission denied. New projects have had this default since a gradual rollout that began on 30 May. Direct Postgres connections aren't affected.

What stays the same

Existing tables keep their current grants and stay reachable. RLS works as before: grants decide whether a role can reach a table, and policies decide which rows it sees. So a table with RLS off that is already granted to anon may still be readable with your public anon key, and a policy that lets one signed-in user read another's rows is unchanged too. The change covers default privileges in public; other schemas keep their current defaults.

What anon and authenticated can reach today

select c.relname as object,
       case c.relkind when 'v' then 'view' when 'm' then 'materialized view'
                      when 'f' then 'foreign table' else 'table' end as kind,
       r.rolname as role,
       concat_ws(', ',
         case when has_any_column_privilege(r.oid, c.oid, 'select') then 'select' end,
         case when has_any_column_privilege(r.oid, c.oid, 'insert') then 'insert' end,
         case when has_any_column_privilege(r.oid, c.oid, 'update') then 'update' end,
         case when has_table_privilege(r.oid, c.oid, 'delete')      then 'delete' end
       ) as can,
       case when c.relkind in ('r', 'p') then c.relrowsecurity::text
            else 'n/a' end as rls_on
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
join pg_roles r on r.rolname in ('anon', 'authenticated')
where n.nspname = 'public'
  and c.relkind in ('r', 'p', 'v', 'm', 'f')
  and has_schema_privilege(r.oid, n.oid, 'usage')
  and (has_any_column_privilege(r.oid, c.oid, 'select, insert, update')
       or has_table_privilege(r.oid, c.oid, 'delete'))
order by c.relname, r.rolname;

How to read the output

Each row is something to review, not a verdict. rls_on = false means that role may read or change any row it has a grant for. n/a marks views and materialized views: RLS doesn't apply to materialized views, and views without security_invoker = true run with the owner's rights. Column-level grants are included. If a role shouldn't reach an object at all, revoke all on table public.your_table from anon, authenticated; (try it on a non-production copy first).

Adding a table after 30 Oct

Put the grant, RLS and policies in the same migration:

grant select on public.your_table to authenticated;
alter table public.your_table enable row level security;
create policy "Owners read their rows" on public.your_table
  for select to authenticated using ( (select auth.uid()) = user_id );

If a tool hits 42501, a bulk grant ... on all tables in schema public clears the error but also re-grants tables you meant to keep private.

Limits

This is a read-only catalog query. It checks the public schema only, lists grants rather than testing your live app or API, and doesn't flag broad policies such as using (true). A clean result doesn't show there are no issues. Run it only on a database you own or are authorised to access.

Sources: Supabase, "Breaking Change: Tables not exposed to Data and GraphQL API automatically" (supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically); Supabase docs, "Securing your API"; PostgreSQL docs, "System Information Functions".

For tables without RLS, using (true) policies and views without security_invoker, the free self-check runs those checks in one read-only SELECT: https://github.com/nightshiftscan/supabase-rls-self-check (Apache-2.0)

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)

DEV Community: Nightshift Scan

Supabase's 30 Oct change: check the tables you already have

What changes on 30 Oct

What stays the same

What anon and authenticated can reach today

How to read the output

Adding a table after 30 Oct

Limits

Three Supabase RLS settings worth checking before launch

1. Tables with RLS disabled

Policies with using (true)

Views without security_invoker = true

How to read the output

Limits

Why it matters

Policies with `using (true)`

Views without `security_invoker = true`