Can supabase_admin create objects in public, and how should its default privileges be hardened?

[jurinek666]

Context

A security audit of two hosted Supabase projects found schema-specific default privileges owned by the internal supabase_admin role in public.

The following read-only query reproduces the finding:

select
  defaclrole::regrole::text as owner_role,
  n.nspname as schema_name,
  defaclobjtype,
  defaclacl
from pg_default_acl
join pg_namespace n on n.oid = defaclnamespace
where defaclrole = 'supabase_admin'::regrole
  and n.nspname = 'public';

For future objects created by supabase_admin, the ACLs grant:

• tables: arwdDxtm to anon and authenticated;
• functions: EXECUTE to anon and authenticated;
• sequences: rwU to anon and authenticated.

Existing customer objects in public are owned by postgres and have been verified as read-only for API roles. We hardened the postgres defaults through a versioned migration. The residual concern applies only if platform automation or upgrades create future objects in public as supabase_admin.

The project postgres role is not a member of supabase_admin, so attempting ALTER DEFAULT PRIVILEGES FOR ROLE supabase_admin from a normal project migration is neither available nor something we want to work around.

Supabase Support ticket: SU-429268. So far we have only received the automatic acknowledgement. Related project issue: https://github.com/jurinek666/database-X/issues/151

Questions

1. Can the managed-platform supabase_admin role create customer-visible objects in the public schema during upgrades, automation, or other supported workflows?
2. If it can, what is the supported way to remove the automatic grants to anon and authenticated from its default privileges?
3. If it cannot, is there an official guarantee or documentation we can reference?
4. Does the explicit Data API exposure rollout described in discussion Breaking Change: Tables not exposed to Data and GraphQL API automatically #45329 also remediate defaults owned by supabase_admin, or only those owned by postgres?
5. Is there a supported staging workflow for creating a one-time test object as the relevant platform role to verify the resulting ACL?

We are intentionally not modifying the internal role or creating test DDL until Supabase confirms a supported procedure.

[aantti]

@jurinek666 I fw'd this to the team.

[ISMEG-0x00]

Hi @jurinek666!

Here are quick answers to your questions regarding supabase_admin:

Does supabase_admin create customer objects in public?
No. Supabase platform automation and internal management scripts run strictly within system schemas (like extensions, auth, storage, vault, etc.). supabase_admin does not create user-facing tables, functions, or views in the public schema during routine upgrades or maintenance.

Can you alter default privileges for supabase_admin?
No, because postgres is intentionally not a member of supabase_admin (a managed platform superuser-level role). Since supabase_admin does not create objects in public, modifying its default privileges is unnecessary for hardening customer schemas.

Data API exposure change (#45329):
This breaking change specifically revokes default schema access and privileges for user-created objects owned by postgres.

Testing / Verifying:
You do not need to test DDL execution as supabase_admin. As long as your project migrations harden default privileges for postgres (ALTER DEFAULT PRIVILEGES FOR ROLE postgres ... IN SCHEMA public), all customer objects created via your migrations/Data API will remain properly locked down.

Since you already submitted ticket SU-429268, the Supabase internal team can confirm the exact platform architecture guarantees directly on your ticket!