Hosted Supabase least-privilege runtime role: PUBLIC TEMP and PostGIS SECURITY DEFINER functions

[ashtonfora]

We are configuring a restricted PostgreSQL role for a server-side application on hosted Supabase, with Supavisor transaction pooling as the intended runtime connection. We would appreciate guidance on the supported privilege boundary before changing platform-related grants.

This is a configuration/support question, not a claim of an exploitable vulnerability. We have not invoked the functions below to test access to protected data, nor changed these platform grants.

1. Database TEMP inherited from PUBLIC

In a saved read-only catalog inspection, the restricted application role had no database CREATE privilege, but effective TEMP was true because the postgres database grants TEMPORARY to PUBLIC. Our application does not require temporary tables.

We understand that revoking TEMP from the individual role cannot override a PUBLIC grant. Is revoking TEMPORARY from PUBLIC and explicitly preserving it for required managed/service roles a supported configuration on hosted Supabase? If so, is there a documented list or policy covering platform services, maintenance, newly introduced roles and upgrades? We do not want to infer service requirements from current ACLs alone or break managed functionality.

If that approach is unsupported, what is the recommended way to maintain this application-specific no-TEMP boundary?

2. PostGIS extension functions

Our saved catalog inspection reported PostgreSQL 17 and PostGIS 3.3.7, with these extension-member functions in the extensions schema:

• st_estimatedextent(text, text, text, boolean)
• st_estimatedextent(text, text, text)
• st_estimatedextent(text, text)

All three were SECURITY DEFINER, owned by supabase_admin, with PUBLIC EXECUTE, effective EXECUTE for the application role, and no function-local search_path setting recorded. These are catalog observations only; we did not establish deployed function-body/binary equivalence or demonstrate a security impact.

Is retaining these defaults the supported configuration for a restricted custom application role? If limiting execution is appropriate, what supported grant change or extension upgrade path preserves Supabase compatibility and survives upgrades? In particular, is there documented guidance on the intended access boundary for these functions?

We have also opened a private support request. This public question intentionally excludes project identifiers, endpoints, credentials and raw logs. References to official guidance or experience with a supported hosted configuration would be very helpful. Thank you.

[Jorge-Polanco-Roque]

Short answer: the mechanics are simple, but I'd think twice before doing this on hosted.

On the TEMP side, you're right that revoking TEMPORARY from the individual role can't override the PUBLIC grant, since the grant to PUBLIC is what makes it effective. The only way to actually close it at the database level is:

REVOKE TEMPORARY ON DATABASE postgres FROM PUBLIC;

and then grant it back to whatever managed roles need it. And that's exactly the problem on hosted: there's no stable, documented list of which platform or maintenance roles rely on TEMP, and any new role a future platform change introduces wouldn't be covered. You'd end up inferring service requirements from the current ACLs, which is the thing you (rightly) said you don't want to do. For a single app's no-TEMP requirement I wouldn't touch the PUBLIC grant on the shared database at all. I'd push that boundary up into a dedicated role/connection your app uses and keep it inside your own schema.

On the PostGIS functions, those defaults (SECURITY DEFINER, PUBLIC EXECUTE) come straight from the PostGIS extension script and are owned by supabase_admin. Two catches there: as postgres on hosted you can't durably revoke an EXECUTE you didn't grant, and even if you could, an extension upgrade re-applies the default grants, so a REVOKE EXECUTE ... FROM PUBLIC won't stick. For context, st_estimatedextent reads planner statistics (pg_statistic) rather than the table data itself, which is why it's SECURITY DEFINER in the first place, so locking it down per role isn't really a supported knob on managed PostGIS.

So for both cases, the boundary that's actually supported is a least-privilege application role plus not exposing these through the Data API (which you're already doing), rather than rewriting platform grants. For a definitive "is this supported on hosted" I'd lean on that private support ticket, since I can really only vouch for the Postgres and PostGIS mechanics here, not the platform policy.