Best practice for Security Advisor RLS warning on public.spatial_ref_sys with PostGIS

[lukasryschka-lgtm]

Question: Best practice for Supabase Security Advisor warning on public.spatial_ref_sys with PostGIS in public

Hi Supabase community,

I’m working on a Supabase project that uses PostGIS. PostGIS is installed in the public schema, and the Supabase Security Advisor reports:

RLS Disabled in Public

The remaining warning points to:

public.spatial_ref_sys

I would like to understand the recommended Supabase/PostGIS best practice before applying any changes.

Current observations

• PostGIS is installed in the public schema.

• public.spatial_ref_sys exists as part of the PostGIS installation.

• The application itself does not directly query public.spatial_ref_sys.

• One application table uses a PostGIS geometry column:

  • public.route_constraints.geometry
  • type: geometry(Geometry, 4326)

• Application tables have RLS enabled.

• The Security Advisor warning that remains is for public.spatial_ref_sys.

• public.spatial_ref_sys currently has RLS disabled.

• There are no application policies on public.spatial_ref_sys.

Current grants observed

For the anon and authenticated roles, the table currently appears to have grants including:

• SELECT
• REFERENCES
• INSERT
• UPDATE
• DELETE
• TRUNCATE
• TRIGGER

I am considering hardening this by revoking write/DDL-like privileges from anon and authenticated, specifically:

• INSERT
• UPDATE
• DELETE
• TRUNCATE
• TRIGGER

I would likely leave SELECT in place unless Supabase/PostGIS guidance says otherwise.

REFERENCES is the main unclear permission. I do not see application foreign keys referencing spatial_ref_sys, but I do not want to break PostGIS behavior by revoking something that PostGIS expects.

Questions

1. For Supabase projects using PostGIS in public, is public.spatial_ref_sys expected to trigger the Security Advisor warning RLS Disabled in Public?

2. Is this warning considered acceptable for the PostGIS system table spatial_ref_sys, or should it be fixed?

3. Is it safe or recommended to enable RLS on public.spatial_ref_sys?

4. If RLS is enabled on public.spatial_ref_sys, are there known risks for PostGIS behavior, geometry/geography type usage, SRID lookups, migrations, or Supabase tooling?

5. Is revoking write/DDL-like grants from anon and authenticated on public.spatial_ref_sys recommended?

   Proposed revokes:

   • INSERT
   • UPDATE
   • DELETE
   • TRUNCATE
   • TRIGGER

6. Should SELECT remain granted to anon and/or authenticated for public.spatial_ref_sys?

7. Should REFERENCES remain granted to anon and/or authenticated, or is it safe to revoke if the application has no foreign keys referencing spatial_ref_sys?

8. What is the safest Supabase-compatible way to address this Advisor finding without breaking PostGIS?

What I want to avoid

I want to avoid applying a migration that makes the Security Advisor quieter but accidentally breaks PostGIS behavior.

I also want to avoid enabling RLS on a PostGIS-managed system table if Supabase or PostGIS expects it to remain unmanaged.

Current intended approach, not yet applied

My current conservative idea is:

• Do not enable RLS on public.spatial_ref_sys until confirmed safe.
• Revoke only write/DDL-like privileges from anon and authenticated.
• Keep SELECT.
• Leave REFERENCES unchanged unless confirmed safe to revoke.
• Treat the Security Advisor warning as unresolved until there is clear guidance.

Does this approach match Supabase/PostGIS best practice?

Thanks!

[PrashantSinghUP64]

I would not enable RLS on spatial_ref_sys just to silence the Advisor warning.

spatial_ref_sys is a PostGIS reference table, not an application-owned table. PostGIS uses it to define available SRIDs and coordinate systems, and functions such as ST_Transform(..., srid) depend on SRID definitions being present. If you enable RLS with no policy, you risk making those rows invisible to normal roles, which can break less obvious spatial code later.

The safer hardening is privilege-based:

revoke insert, update, delete, truncate, trigger
on table public.spatial_ref_sys
from anon, authenticated;

I would keep SELECT, especially if client-accessible code or RPC functions may ever call PostGIS functions that need SRID metadata. spatial_ref_sys is not secret data; it is basically coordinate-system metadata.

For REFERENCES, it is probably safe to revoke if your app has no foreign keys to spatial_ref_sys, but I would treat that as optional hardening rather than the main fix:

revoke references
on table public.spatial_ref_sys
from anon, authenticated;

So my conservative approach would be:

1. Do not enable RLS on spatial_ref_sys.
2. Revoke write-like privileges from anon and authenticated.
3. Keep SELECT.
4. Optionally revoke REFERENCES if you do not use FK references to SRIDs.
5. Document the remaining Advisor warning as an extension-managed PostGIS table exception.

For new projects, the cleaner long-term setup is enabling PostGIS in a dedicated schema such as gis/extensions rather than public, but moving an existing PostGIS extension is more disruptive and should be handled carefully.

[lukasryschka-lgtm]

Thanks

[harrysun2006]

This is a known, benign advisor finding rather than something you need to "fix". spatial_ref_sys is a PostGIS system reference table (SRID definitions) owned by the extension — you generally can't enable RLS on it, and forcing RLS on it can break PostGIS.

Recommended options, roughly in order of preference:

1. Accept / ignore the warning — the table holds reference data, not user data.
2. If you don't want it exposed through the auto-generated API:

   revoke all on public.spatial_ref_sys from anon, authenticated;

3. Cleanest long-term: install PostGIS into a dedicated extensions schema instead of public, so the advisor stays quiet and public only contains your own tables.

I would not try to enable RLS directly on spatial_ref_sys.

[PrashantSinghUP64]

Thanks, that makes sense. I agree with this framing: treat it as a benign extension-managed table warning, not something to fix with RLS.

The distinction around exposure through the auto-generated API is helpful too. If the app does not need client/API access to spatial_ref_sys, revoke all on public.spatial_ref_sys from anon, authenticated; is the cleanest hardening step. If some app/RPC path does rely on SRID metadata lookup, then keeping SELECT is the conservative option.

Either way, I agree the important part is not trying to force RLS onto the PostGIS-managed table. Installing PostGIS outside public for new projects also seems like the best long-term way to avoid this advisor noise.

[mangiapanejohn-dev]

Short version: don't enable RLS on spatial_ref_sys — you generally can't, and you don't need to.

spatial_ref_sys is a reference table created and owned by the PostGIS extension (it stores SRID/projection definitions — static reference data, not user data). Because PostGIS installs into public, the linter flags it under the "RLS Disabled in Public" advisor (Database Advisors: https://supabase.com/docs/guides/database/database-advisors). It's a known, benign finding.

Note that forcing RLS usually fails anyway, since you don't own the extension's table:

alter table public.spatial_ref_sys enable row level security;
-- ERROR: must be owner of table spatial_ref_sys

So pick one of these instead:

1) Reduce the write surface but keep it working (simplest):

revoke insert, update, delete, truncate on table public.spatial_ref_sys
  from anon, authenticated;
-- keep SELECT — PostGIS reads this table

2) Cleanest long-term — keep PostGIS out of the exposed schema so it isn't in the Data API surface at all (Supabase only exposes the schemas you choose: https://supabase.com/docs/guides/api/using-custom-schemas). This has to be done when the extension is installed:

drop extension if exists postgis;         -- only if nothing depends on it yet
create extension postgis schema extensions;

3) Just acknowledge the finding in the Advisor if the table isn't API-exposed in your project — it's informational, not a data leak, because the contents are static SRID definitions.

References: Row Level Security — https://supabase.com/docs/guides/database/postgres/row-level-security · installing extensions in a dedicated schema — https://supabase.com/docs/guides/database/extensions

[PrashantSinghUP64]

Thanks, this is a useful clarification, especially the ownership point.

The must be owner of table spatial_ref_sys behavior is a good practical reason not to chase the RLS warning directly. I also agree with the split you described: if the goal is just to reduce risk while leaving PostGIS in public, revoke write privileges and keep SELECT; if the goal is to keep extension tables out of the exposed API surface entirely, install PostGIS into a dedicated schema from the start.

That makes the advisor finding much less scary: it is worth acknowledging/documenting, but it is not the same class of issue as an application table in public with RLS disabled.

[yakubka]

The Security Advisor warning on public.spatial_ref_sys is a false positive in the context of PostGIS. The table is a read-only reference table shipped by the PostGIS extension and contains coordinate system definitions. No user data lives in it.

You have two practical options.

Option 1. Add a permissive SELECT policy and enable RLS. This silences the advisor and is technically correct since the table is public reference data:

ALTER TABLE public.spatial_ref_sys ENABLE ROW LEVEL SECURITY;
CREATE POLICY spatial_ref_sys_read ON public.spatial_ref_sys FOR SELECT USING (true);

Option 2. Move PostGIS to its own schema (recommended for new projects). Install the extension into an extensions schema so it is isolated from your application tables:

CREATE SCHEMA IF NOT EXISTS extensions;
CREATE EXTENSION IF NOT EXISTS postgis SCHEMA extensions;

Then reference geometries as extensions.geometry, etc. The advisor only flags tables in the public schema.

For existing projects option 1 is simpler and carries no risk since the table is insert-protected by the extension itself. Neither option changes the behavior of your application.