anon/authenticated unexpectedly have TRUNCATE and TRIGGER on public/storage tables in new Supabase project

[SaidNMA]

We created a new Supabase project and applied our migration set successfully.
During a least-privilege audit, we found that anon and authenticated have TRUNCATE and TRIGGER privileges on 39 tables:
36 tables in public
3 tables in storage
Total: 156 grants.
We traced the default ACL sources to:
supabase_admin → public
postgres → public/storage
Attempting to modify the managed defaults from the available postgres connection fails with:
42501 — permission denied to change default privileges
A transactional test showed that explicit:
REVOKE TRUNCATE, TRIGGER
succeeds for the 36 public tables, but the grants remain on:
storage.buckets
storage.objects
storage.buckets_analytics
We rolled the test back and have not modified production privileges.
RLS remains enabled and policies are correct, but we want to enforce strict least privilege before production rollout.
Could someone clarify:
Are these TRUNCATE / TRIGGER grants expected managed defaults?
Can anon or authenticated actually exercise them despite RLS?
What is the supported way to revoke them from existing public and storage tables?
What is the supported way to change the managed default privileges so future tables do not receive them?
Would removing these grants interfere with Supabase Storage or other managed services?

[GaryAustin1]

You will not be able to change storage but by default there is no access from the REST API to them.

It appears default is supabase removes SELECT/UPDATE/INSERT/DELETE as the REST API could use those. There recent lockdown of grants for for the REST API. You can't truncate from the API directly. So unless your write a trigger function to do truncate or you use those roles thru the DB interface on your own Truncate can't be used.

related:
https://github.com/orgs/supabase/discussions/47183

Besides revoking, not clear you can set a default, but I've not done much research on it.

[basildraz-arch]

Adding the parts that are still open, from having run this exact audit on a production project.

1. Yes, these are managed defaults, not something your migrations did. You can see exactly who set them:

select pg_get_userbyid(defaclrole) as granted_by,
       defaclnamespace::regnamespace as schema,
       defaclobjtype,
       defaclacl
from pg_default_acl;

The rows whose granted_by is postgres are yours to change. The ones owned by supabase_admin are not, and that is exactly the 42501 you hit — you can only alter default privileges for a role you are a member of.

2. To stop future tables from receiving them, run this as postgres (the role your migrations create tables as — that is what makes it apply):

alter default privileges for role postgres in schema public
  revoke truncate, trigger on tables from anon, authenticated;

Then query pg_default_acl again to confirm. "The statement ran" is not confirmation.

3. Existing tables — your transactional test was right, and it is safe:

revoke truncate, trigger on all tables in schema public from anon, authenticated;

storage.buckets, storage.objects and storage.buckets_analytics are owned by supabase_admin, so the revoke does nothing there. That is expected. Leave them; the Storage API does not reach those tables as anon.

4. Can anon actually exercise TRUNCATE or TRIGGER? Not through the REST API. PostgREST emits no DDL and no TRUNCATE, and anon/authenticated are NOLOGIN roles, so nobody connects as them directly. The one path worth checking before you call it closed: a SECURITY INVOKER function reachable over RPC that truncates a table or creates a trigger internally. That runs with the caller's privileges, and the grant is what would let it succeed. Check the grant itself rather than reasoning about it:

select has_table_privilege('anon', 'public.your_table', 'TRUNCATE');

5. Where I would spend the rest of a least-privilege audit. TRUNCATE and TRIGGER on anon are untidy but not reachable from a browser. These two are, and they survive policies that are correct as written:

• Column privileges are asymmetric. A column you add later is denied for reads until you grant, and allowed for writes until you revoke. A table-level GRANT UPDATE covers every future column, and a column-level REVOKE underneath it fails silently. has_column_privilege per column is the check that catches it.
• create function grants EXECUTE to PUBLIC, and anon inherits PUBLIC, so revoke ... from anon alone closes nothing. select has_function_privilege('anon', 'public.f()', 'execute') settles it in one line.

Both of those are reachable by anyone holding your anon key, which TRUNCATE is not — so if you are prioritising before rollout, I would do those two first and treat the TRUNCATE/TRIGGER cleanup as hygiene.

The read-only version of these checks, if it saves you writing them: https://github.com/basildraz-arch/supabase-rls-audit

[cekuu35]

Sizin gözlemlediğiniz TRUNCATE/TRIGGER grant'ları managed default ACL kaynaklıdır — ve çok büyük olasılıkla supabase_admin'den gelen ALTER DEFAULT PRIVILEGES kalıntısı değil, doğrudan tablo oluşturma anındaki sahiplik zincirinden gelir.

Kısaca: storage.buckets / storage.objects tablolarını supabase databases yaratırken sahip rol = supabase_storage_admin-olmayan bir üst rol altında oluşturur ve storage schema'sındaki default ACL'ler postgres'e ALL verir. Supabase'in managed pg_defaults'u storage damarını postgres rolüne devrettiği için, TRUNCATE/TRIGGER dahil ALL grant'ları her iki tarafa (public + storage) aynen yansır.

Soru 2 — anon/authenticated bunları kullanabilir mi? Çoğu durumda hayır, iki katman engeller: (1) storage schema'sındaki tablolarda RLS açıktır, (2) anon için TRACE yine de Storage API'nin yalnızca supabase_service_role ile yaptığı internal işlemdir. Yine de bunların GRANT gözükmesi, bir RLS politikasının yanlış yazılması halinde TRUNCATE'i açıkta bırakır — ki “least privilege” hedefinizle tam da çelişen senaryo budur.

Soru 3 & 4 — desteklenen revoke yolu: REVOKE TRUNCATE, TRIGGER ON TABLE storage.buckets FROM anon gibi tek tek revoke güvenli ve desteklenir; ama iki SEO gerektirir:

DO $$
DECLARE r record;
BEGIN
  FOR r IN
    SELECT schemaname, tablename
    FROM pg_tables
    WHERE schemaname IN ('storage')
  LOOP
    EXECUTE format('REVOKE TRUNCATE, TRIGGER ON %I.%I FROM anon, authenticated', r.schemaname, r.tablename);
  END LOOP;
END
$$;

Mevcut tablolarda bu çalışır. Gelecekteki tablolar için ise storage damarının bu default ACL'leri postgres'e verdiği için doğrudan ALTER DEFAULT PRIVILEGES değiştirmek Supabase tarafından managed olduğundan kalıcı garantilenmez — her migration/deploy sonrası tekrar uygulanabilir bir migration (yukarıdaki DO bloğu) kalıcı çözümdür.

Soru 5 — Storage'ı kırar mı? Kırmaz. Storage API asla anon/authenticated rolüyle TRUNCATE/CREATE TRIGGER yapmaz; storage işlemleri supabase_service_role / supabase_storage_admin ile yürür (RLS bypass + rol grant'ı ayrı). Bu yüzden anon/authenticated'ten bu iki yetkiyi almak storage upload/download/delete davranışını değiştirmez, yalnızca saldırı yüzeyini daraltır. Test etmeden :

-- UPLOAD: çalışıyor mu?
mkdir('revoke-test-'+now()::text)

İsterseniz DO bloğunu başka bir migration'a ekleyip storage grant'larını çıkarmadan önce aynı sorguyu bir daha koşarak farkı doğrulayabilirim.

[cekuu35]

This is Postgres default grants — new Supabase projects grant TRUNCATE + TRIGGER on storage.objects to PUBLIC by default (see pg_default_acl).

Verify:

SELECT * FROM pg_default_acl WHERE defaclobjtype = 'r' AND defaclnamespace = 'storage'::regnamespace;

Fix (revoke unwanted defaults):

ALTER DEFAULT PRIVILEGES IN SCHEMA storage REVOKE TRUNCATE, TRIGGER ON TABLES FROM PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA storage REVOKE TRUNCATE, TRIGGER ON TABLES FROM anon;
ALTER DEFAULT PRIVILEGES IN SCHEMA storage REVOKE TRUNCATE, TRIGGER ON TABLES FROM authenticated;
-- Then re-grant only what you need:
ALTER DEFAULT PRIVILEGES IN SCHEMA storage GRANT SELECT ON TABLES TO anon;
ALTER DEFAULT PRIVILEGES IN SCHEMA storage GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO authenticated;

Note: This affects future tables. For existing tables, revoke explicitly:

REVOKE TRUNCATE, TRIGGER ON storage.objects FROM PUBLIC, anon, authenticated;

Free audit script: https://github.com/cekuu35/supabase-rls-leak-demo

[basildraz-arch]

Three corrections on the answer above, because this is a hardening pass before production and one of those steps can take Storage down.

1. Check the grantee before you write the revoke.

The opening post says the grants sit on anon and authenticated. The answer above revokes from PUBLIC. Those are different grantees and a revoke aimed at the wrong one succeeds silently and changes nothing. Ask first:

select grantee, privilege_type
from information_schema.role_table_grants
where table_schema = 'storage'
  and table_name in ('objects','buckets','buckets_analytics')
  and privilege_type in ('TRUNCATE','TRIGGER')
order by grantee, privilege_type;

2. alter default privileges in schema storage ... as postgres will not reach storage tables.

Default privileges are recorded per (owner role, schema). With no for role clause the statement records defaults for objects created by the role running it. Storage tables are created by supabase_storage_admin, so a default ACL owned by postgres never applies to them. The statement returns success and nothing changes — which is the same wall as the 42501 in the opening post, just quieter. Read the catalog rather than the exit code:

select pg_get_userbyid(defaclrole) as owner,
       defaclnamespace::regnamespace as schema,
       defaclacl
from pg_default_acl
where defaclnamespace = 'storage'::regnamespace;

3. This is the one that matters: do not widen the revoke on storage.objects past TRUNCATE and TRIGGER.

SELECT, INSERT, UPDATE and DELETE for anon and authenticated on storage.objects are load-bearing on a stock project. Storage policies are written to authenticated and are evaluated as that role, so the grant is what lets the policy be reached at all. Take those away and every upload starts returning

403 new row violates row-level security policy

which reads like a policy problem and is not one. It is one of the more common causes of that error, and it is painful to diagnose precisely because the policies are correct. The loop in the answer above revokes TRUNCATE, TRIGGER only, so it is safe as written — I am flagging it because the re-grant lines underneath it invite editing that list, and that list is not a safe thing to edit by hand.

For the same reason I would leave the future-tables default alone in storage rather than setting

alter default privileges in schema storage
  grant select, insert, update, delete on tables to authenticated;

That is a standing rule that every table Supabase adds to storage in a later platform update is fully writable by anyone with a session, before you have seen it or written a policy for it. Narrower than that is to do nothing: as established in point 2, the statement will not apply to storage-owned tables anyway.

On the original question, the short version: TRUNCATE and TRIGGER on anon are untidy but not reachable from a browser — PostgREST emits no DDL and no TRUNCATE, and anon/authenticated are NOLOGIN. Clean them in public, leave storage alone, and verify with has_table_privilege rather than with the fact that the migration ran.