Description
Ensure Postgres extensions are installed in a dedicated schema, such as the extensions schema, instead of the public schema. The public schema should contain only the application's own tables, views, and functions that are meant to be exposed through the Data API.
Rationale
The public schema is exposed through the Data API by default. Extensions installed there add their own functions and objects to that schema, which may then be reachable through the API or clash with application objects. Keeping extensions in a separate schema reduces what is exposed and keeps the public schema clean and easier to secure.
Impact
Reduces the objects exposed through the Data API
Keeps the public schema limited to application objects
Code that calls extension functions may need the new schema name
Default Value
Extensions can be installed into any schema. When enabled from the Dashboard, you choose the schema, and Supabase uses an extensions schema for many common extensions.
Pre-Requisites
Project Owner or Admin role
Access to the SQL Editor
Test Plan
Sign in to the Supabase Dashboard at https://supabase.com/dashboard.
Select your project.
Open Advisors in the sidebar and select Security Advisor.
Check for the finding Extension in Public.
If any extension is listed, follow the implementation steps.
Implementation Steps
Sign in to the Supabase Dashboard at https://supabase.com/dashboard.
Select your project.
Open the SQL Editor in the sidebar.
For each listed extension that supports it, run: alter extension <extension_name> set schema extensions;
If an extension cannot be moved, drop it and recreate it in the extensions schema.
Update any code that calls the extension's functions with the public schema name.
Backout Plan
Sign in to the Supabase Dashboard at https://supabase.com/dashboard.
Select your project.
Open the SQL Editor in the sidebar.
Run: alter extension <extension_name> set schema public;
Reference