How can a project owner revoke PUBLIC privileges on the net schema (pg_net)?

[burhansabanoglu-commits]

On a hosted Supabase project (Postgres 17), the pg_net objects are granted to PUBLIC, which transitively includes anon:

select relacl from pg_class c join pg_namespace n on n.oid = c.relnamespace
 where n.nspname = 'net' and c.relname = 'http_request_queue';
-- {supabase_admin=arwdDxtm/supabase_admin,=arwdDxtm/supabase_admin}
--                                         ^ empty grantee = PUBLIC

has_schema_privilege('anon','net','USAGE')                    -> true
has_table_privilege('anon','net.http_request_queue','SELECT') -> true
has_table_privilege('anon','net._http_response','SELECT')     -> true
has_function_privilege('anon','net.http_post(...)','EXECUTE') -> true

net.http_request_queue stores the headers of outgoing requests, so anything able to read it can read whatever Authorization or custom auth headers your pg_cron jobs send to Edge Functions.

The part I'm stuck on: I can't revoke it

revoke all on all tables in schema net from public;
revoke usage on schema net from anon;
-- WARNING: no privileges could be revoked

The ACL is unchanged afterwards, because:

(select rolsuper from pg_roles where rolname='postgres')  -> false
pg_has_role('postgres','supabase_admin','MEMBER')         -> false
extowner of pg_net                                        -> supabase_admin

postgres is neither superuser nor a member of the owning role, so the REVOKE is a no-op. Worth highlighting for anyone else hitting this: it does not raise an error, only a WARNING — a migration that does this looks like it succeeded and silently changes nothing.

Questions

1. Is granting the net schema to PUBLIC intentional on hosted projects, or a packaging artifact?
2. Is there any supported self-serve way for a project owner to revoke it? Specifically, if I toggle the extension off and on in Dashboard → Database → Extensions, does the recreated extension come back with the same PUBLIC grants?
3. If it has to stay, is there a documented reason it's safe — e.g. a guarantee that PostgREST will never expose net?

What I measured on my side, in case it helps others who find this

The grant is open, but it is not reachable through the API. Using the project's anon key:

GET  /rest/v1/_http_response   (Accept-Profile: net)   -> 406 PGRST106
     "Only the following schemas are exposed: public, graphql_public"
POST /rest/v1/rpc/http_post    (Content-Profile: net)  -> 406 PGRST106
GET  /rest/v1/http_request_queue                       -> 404

So it only becomes exploitable if something in an exposed schema bridges to it — e.g. a public function that calls net.* and is executable by anon. I now monitor for exactly that condition, but I'd rather close the grant itself than rely on a tripwire.

[silentworks]

From the Data API surface (PostgREST) the net schema is not exposed. You shouldn't need to worry about the default privileges set on this schema. Also as you stated you cannot modify the privileges as the roles you have access to are not the owners of that schema. There are no known security issue with this setup, no one has reported any and Supabase haven't reported any either.

[paramjeetn]

Regarding the pg_net permissions on hosted Supabase:

1. Why postgres role gets WARNING: no privileges could be revoked:
   On hosted Supabase, extensions created via the dashboard or platform default are owned by the internal supabase_admin role. In PostgreSQL, only the object owner or a superuser can revoke privileges granted by that owner. Since the postgres user does not have superuser privileges on managed instances, running REVOKE ... FROM PUBLIC is ignored as a no-op.

2. Security & PostgREST Exposure Guarantee:
   As you noted from your 406 PGRST106 testing, PostgREST strictly isolates schemas using the db-schemas configuration (which only exposes public, graphql_public, and explicitly whitelisted schemas). Because PostgREST never includes net in its search path, anonymous and authenticated HTTP requests cannot invoke net.http_post or read net.http_request_queue unless a function in public with SECURITY DEFINER explicitly executes it.

3. Recommended Protection Pattern:
   To ensure zero leak path from custom RPCs:

• Keep all custom DB functions calling net isolated to private non-exposed schemas (e.g. private.trigger_job()).
• Audit pg_proc to verify no function in public or graphql_public contains calls to net.* while being executable by anon or authenticated.

[cekuu35]

Your analysis is spot-on, and the fact that you've already measured the actual PostgREST surface (406 PGRST106) is the right approach. The net schema is indeed not exposed by PostgREST's db-schemas configuration, so it's not directly reachable through the API.

But your instinct about the "bridge" vector is exactly right. Here's a concrete way to monitor for it:

-- Check if any role with API access has direct EXECUTE on net functions
SELECT
    r.rolname AS grantee,
    has_function_privilege(r.rolname, 'net.http_post(text, jsonb, text)', 'EXECUTE') AS can_http_post,
    has_schema_privilege(r.rolname, 'net', 'USAGE') AS has_net_usage
FROM pg_roles r
WHERE r.rolname IN ('anon', 'authenticated', 'service_role');

And a query to find SECURITY DEFINER functions in exposed schemas that reference net.*:

SELECT p.proname, n.nspname, pg_get_functiondef(p.oid)
FROM pg_proc p
JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE n.nspname IN ('public', 'graphql_public')
  AND p.prosecdef = true
  AND pg_get_functiondef(p.oid) ~ 'net\\.';

This gives you a tripwire: if someone creates a SECURITY DEFINER function in public that calls net.*, or if a future migration grants net access to an API-visible role, you'll catch it.

On the self-serve revocation question: as others noted, postgres can't revoke grants owned by supabase_admin. But you can narrow the bridge surface by explicitly controlling EXECUTE grants on your own functions:

-- Revoke broad EXECUTE, then re-grant only what's needed
REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA public FROM anon;
REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA public FROM authenticated;
GRANT EXECUTE ON FUNCTION your_safe_function(args) TO authenticated;

This doesn't close the net grant itself, but it ensures no function you own can be a bridge unless you explicitly allow it.

[SebastianElustondo]

Agree with the analysis above: you can't revoke it because supabase_admin owns the extension, and PostgREST doesn't expose net. But the "bridge" you're worried about is worth spelling out, because I hit it in production and it's the part you can control.

On a Supabase project, every function you create in public is executable by anon and authenticated out of the box: the platform sets default privileges for the postgres role that grant EXECUTE to those API roles. So the real question isn't whether net is readable, it's whether any SECURITY DEFINER function reachable via /rest/v1/rpc/... calls into it (or into anything else sensitive). In my case a definer function that read a payment-provider token was callable with the public anon key. Nothing in net, same shape of problem.

What fixed it, and what I'd do here:
-- stop future functions from being callable by the API roles by default
alter default privileges for role postgres in schema public
revoke execute on functions from anon, authenticated;

-- close the ones that already exist
revoke execute on all functions in schema public from anon, authenticated;
-- then grant back only what the app really calls, one by one
grant execute on function public.book_slot(uuid, timestamptz) to authenticated;

Verify from the role's point of view, not as postgres:
begin;
set local role anon;
select has_function_privilege('public.trigger_job()', 'execute'); -- want: false
rollback;

and from outside, curl -X POST .../rest/v1/rpc/trigger_job -H "apikey: " should now come back with a permission error instead of running. The tripwire query cekuu35 posted is a good complement: run it in CI so a new definer function that touches net.* fails the build.

On your question 2: I haven't tested toggling the extension, but the grants come from the extension's own install script, so I'd expect them to come back identical.