---
title: "Supabase \"RLS disabled in public\": qué significa"
description: "Qué significa el aviso rls_disabled_in_public del Advisor de Supabase, qué hizo la clave pública con esa tabla en mi prueba local y cómo corregirlo."
url: "https://madsalt.tech/es/notes/supabase-rls-disabled-in-public/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/es/about/"
language: "es"
published: 2026-10-28
---

# Supabase "RLS disabled in public": qué significa

En resumen

"RLS Disabled in Public" (lint `0013_rls_disabled_in_public`, nivel ERROR) significa que una tabla de un esquema expuesto tiene el row level security desactivado mientras `anon` o `authenticated` pueden hacerle select. En mi prueba local, la clave pública leyó las 3 filas de 3 de una tabla así e insertó una nueva con `201 Created`. Active RLS, añada una política por operación y revise los grants, todo en una migración.

Construí un [verificador de seguridad de Supabase](https://madsalt.tech/es/tools/supabase-security-check/) gratuito, y su primera regla, "RLS desactivado en tablas expuestas", es el mismo hallazgo que el Security Advisor de Supabase informa como un error. Es el hueco más común que encuentro en apps hechas con herramientas de IA, así que aquí está qué significa y qué permitió cuando lo reproduje.

## ¿Qué significa "RLS disabled in public"?

El Security Advisor ejecuta un lint llamado `rls_disabled_in_public`. Su [SQL](https://github.com/supabase/splinter/issues/82) señala una tabla cuando se dan tres cosas a la vez:

1. Es una tabla ordinaria con el row level security desactivado.
2. `anon` o `authenticated` tienen `SELECT` sobre ella.
3. Su esquema está en la lista Exposed schemas de la Data API, que por defecto es `public`.

La [página del lint](https://supabase.github.io/splinter/0013_rls_disabled_in_public/) lo clasifica como ERROR y llama a tener crear, leer, actualizar y borrar completos a través de internet "a critically unsafe configuration" (una configuración críticamente insegura). El "public" del nombre es el esquema, pero el lint cubre todos los esquemas expuestos, y por eso conviene mirar también un esquema extra en esa lista; lo conté en [Supabase exposed schemas](https://madsalt.tech/es/notes/supabase-exposed-schemas/).

## ¿Qué puede hacer la clave pública con esa tabla?

Creé una tabla `orders` con tres clientes falsos en un stack local de Supabase (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), con los grants que los proyectos existentes dan a las tablas nuevas, y RLS desactivado. Después llamé a la Data API con la publishable key, como lo hace un navegador:

![Una tabla, la clave pública, con RLS desactivado y activado. Supabase local, 3 filas de pedidos falsos. RLS desactivado, lectura: Publishable key → orders, sin RLS → 3 de 3 filas; RLS desactivado, inserción: Publishable key → orders, sin RLS → 201 Created; RLS activado, aún sin política: Publishable key → orders, con RLS → 0 filas.](https://madsalt.tech/charts/es/supabase-rls-disabled-in-public.svg)

*Mi reproducción en un stack local de Supabase, 23 de octubre de 2026.*

| Petición con la publishable key           | RLS desactivado                          | RLS activado, sin política                                |
| ----------------------------------------- | ---------------------------------------- | --------------------------------------------------------- |
| `GET /rest/v1/orders?select=*`            | `200`, las 3 filas con nombres y correos | `200`, `[]`                                               |
| `POST /rest/v1/orders` con una fila nueva | `201 Created`                            | `401`, 42501 "new row violates row-level security policy" |

Cualquiera que abra su app puede copiar la publishable key de la página. Con RLS desactivado, la clave es un pase de lectura y escritura a esa tabla.

## ¿Cómo se corrige sin romper la app?

Activar solo RLS hace que la tabla no devuelva nada a la app, porque todavía no hay ninguna política. Esa pantalla vacía es cuando la gente, y las herramientas de IA, añaden una política con `using (true)`, que devuelve todas las filas a todo el mundo. Por qué los updates y deletes informan entonces de éxito sin cambiar nada está en [Cómo activar RLS en Supabase y qué devuelve](https://madsalt.tech/es/blog/how-to-enable-rls-in-supabase/). Escriba las políticas reales en la misma migración:

```sql
alter table public.orders enable row level security;

revoke all on table public.orders from anon, authenticated;
grant select, insert on table public.orders to authenticated;

create policy "Customers read their orders"
on public.orders for select
to authenticated
using ((select auth.uid()) = user_id);

create policy "Customers create their orders"
on public.orders for insert
to authenticated
with check ((select auth.uid()) = user_id);
```

Si una tabla debe ser pública, como una lista de artículos publicados, mantenga RLS activado de todos modos y escriba una sola política `select` para `anon`, sin grants de escritura. Si nunca usa la Data API y habla con Postgres solo desde su servidor, quite `public` de Exposed schemas, como sugirieron los mantenedores de Supabase en el [mismo issue](https://github.com/supabase/splinter/issues/82).

Para asegurarse de que las tablas nuevas nunca empiecen sin RLS, la [guía de event triggers](https://supabase.com/docs/guides/database/postgres/event-triggers) de Supabase tiene un trigger que lo activa en cada tabla creada en `public`. Y desde el 30 de octubre de 2026 las tablas nuevas no reciben grants de la Data API por defecto, así que responden `42501` hasta que usted las conceda; lo traté en [Supabase 42501 permission denied](https://madsalt.tech/es/notes/supabase-42501-permission-denied/).

## ¿Qué no demuestra un resultado limpio?

Que RLS esté activado no dice nada sobre si las políticas son correctas. En la misma prueba, una política escrita como `using (true)` volvió a darle a la clave pública las 3 filas, y este lint se queda callado en cuanto RLS está activado. El verificador tiene una regla aparte para eso, "Políticas que permiten todas las filas", y [cómo probar Supabase RLS](https://madsalt.tech/es/blog/how-to-test-supabase-rls/) muestra cómo demostrar cada política con usuarios reales. Políticas para empezar, cada una probada con usuarios reales a través de la API, están en [Políticas RLS de Supabase: ejemplos probados con la API](https://madsalt.tech/es/blog/supabase-rls-policy-examples/).