# Ensure Row Level Security (RLS) is enabled on all public schema tables

- Source: https://support.icompaas.com/support/solutions/articles/a_1790103900799613-ensure-row-level-security-rls-is-enabled-on-all-public-schema-tables
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Supabase cloud](https://support.icompaas.com/support/solutions/c_1790103054038308) › [supabase checks](https://support.icompaas.com/support/solutions/folders/f_1790103067540538)
- Last updated: 2026-09-22
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure Row Level Security (RLS) is enabled on every table in the public schema, and on any other schema exposed through the Data API. With RLS enabled, rows can only be read or changed when a policy allows it, instead of being open to anyone who has the project URL and publishable key.

**Rationale**

Tables in the public schema are available through Supabase's auto-generated APIs. If RLS is not enabled, anyone with the project URL and the public key can read, insert, update, and delete every row in the table. This is one of the most common and serious Supabase misconfigurations, and it can expose all application data to the internet.

**Impact**

-   Blocks open read and write access to public tables
    
-   Access then depends on the policies you create
    
-   Tables with RLS but no policies deny all API access
    

**Default Value**

RLS is enabled by default for tables created in the Table Editor. Tables created with SQL or migration tools do not have RLS enabled unless you enable it.

**Pre-Requisites**

-   Project Owner, Admin, or Developer role
    
-   Access to the SQL Editor
    

**Test Plan**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open Advisors in the sidebar and select Security Advisor.
    
4.  Check for the finding RLS Disabled in Public.
    
5.  If any table is listed, follow the implementation steps.
    

**Implementation Steps**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open the SQL Editor in the sidebar.
    
4.  For each listed table, run: alter table public.<table\_name> enable row level security;
    
5.  Create policies for the access each table needs.
    
6.  Rerun the Security Advisor and confirm the finding is resolved.
    

**Backout Plan**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open the SQL Editor in the sidebar.
    
4.  Run: alter table public.<table\_name> disable row level security;
    

**Reference**

-   [https://supabase.com/docs/guides/database/postgres/row-level-security](https://supabase.com/docs/guides/database/postgres/row-level-security)
    
-   [https://supabase.com/docs/guides/database/database-advisors?lint=0013\_rls\_disabled\_in\_public](https://supabase.com/docs/guides/database/database-advisors?lint=0013_rls_disabled_in_public)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.