Supabase "RLS disabled in public": lo que el aviso no ve

Abriste el Security Advisor en tu dashboard de Supabase, o alguien te pegó su salida delante, y ahí está en rojo: RLS disabled in public. Debajo, una línea por tabla, con las palabras de Supabase:

Table public.profiles is public, but RLS has not been enabled.

Aquí está la parte que guía tras guía cuenta mal: vaciar esa lista no significa que nadie pueda leer tus datos. El advisor tiene una regla aparte para una política que deja entrar a todo el mundo, y esa regla se salta justo la forma que escribe un constructor de IA cuando desatasca tu app. Así que la lista que acabas de arreglar y la lista de tablas que un desconocido puede leer son dos listas distintas, y una de ellas no aparece en ningún sitio de tu dashboard.

¿Qué significa "RLS disabled in public"?

Una tabla de tu esquema public tiene Row Level Security apagado, y la consecuencia es que cualquiera con la dirección de tu proyecto puede leer todas sus filas.

Las dos mitades de esa frase necesitan explicación. El esquema public es donde va una tabla cuando nadie dice otra cosa, y es la parte de tu base de datos que Supabase publica en la web: cada proyecto responde peticiones en una dirección propia, y la clave que hace falta para hablar con ella está en el código que tu web envía a cada visitante. Row Level Security es el interruptor que decide si tus reglas se consultan antes de entregar filas. Con él apagado no hay nada que consultar, así que la respuesta siempre es que sí.

Esa combinación es la razón de que esto se reporte como error y no como aviso. El advisor clasifica sus hallazgos, y este es el escalón más alto.

Piensa en el advisor como un inspector con un portapapeles. Lee tu documentación con cuidado y lo hace bien. Nunca prueba el picaporte. Nada de lo que hay en ese panel es el resultado de una petición que alguien haya hecho a tu base de datos.

¿Activar RLS va a romper mi app?

Sí, de inmediato, y eso es el interruptor funcionando.

El arreglo que te da Supabase es una línea, y la ejecutas en el SQL Editor:

alter table public.profiles enable row level security;

La propia documentación de Supabase es clara sobre lo que pasa después: los datos dejan de ser accesibles por la API con una clave publicable mientras no haya políticas definidas. Así que tus listas vuelven vacías, tus pantallas se quedan en blanco, y el error del advisor queda sustituido por una entrada más discreta que dice que la tabla tiene RLS activado pero ninguna política.

Esa es la puerta cerrada sin nadie todavía en la lista. Lo siguiente que hace casi todo el mundo es añadir una política que deja leer a cualquiera, porque eso es lo que hace que las pantallas vuelvan.

El fallo que el aviso no está buscando

Una tabla con Row Level Security encendido y una política de lectura cuya condición es USING (true) entrega exactamente las mismas filas al mismo desconocido. El advisor no la marca.

No es un descuido. Supabase sí tiene una regla para las políticas siempre verdaderas, y deja fuera las de lectura a propósito. Su propia descripción de la regla lo dice:

SELECT policies with `USING (true)` are intentionally excluded as this
pattern is often used deliberately for public read access.

En el caso general la regla tiene razón. Un catálogo de productos, una lista de artículos publicados, un mapa de locales: eso está pensado para que lo lea cualquiera, y marcarlo entrenaría a todos los desarrolladores de la plataforma para ignorar el panel. Lo que ningún linter puede saber es si la tabla que está mirando guarda locales o clientes.

Y una política que deja leer a todos es la forma más rápida de volver a poner en pie una app rota, que es por lo que un constructor de IA tira de ella. Pídele a Cursor o a Lovable que arregle las pantallas vacías y FOR SELECT USING (true) es una respuesta habitual. Tu app carga, el error desaparece, el panel se calla, y la tabla se lee igual que antes de empezar.

Las dos filas donde no se reporta nada en absoluto son el par que merece un momento. Una es una tabla que nadie fuera de tu app puede tocar. La otra es una tabla que puede leer cualquiera. Tu dashboard calla igual con las dos.

Cómo se escribió esa política, y por qué sustituirla tabla por tabla, es el tema de Row Level Security está activado y tu tabla sigue pública. Si esa misma política también tiene que dejar que tu app guarde datos, el error que te encuentras después es new row violates row-level security policy.

Por qué la tabla que hiciste con una migración nunca te avisó

Porque el Table Editor enciende Row Level Security por ti y SQL no.

Supabase documenta la diferencia sin rodeos: las tablas creadas con el Table Editor del dashboard tienen RLS activado por defecto, y las creadas con SQL directo hay que activarlas de forma explícita. Una tabla que creaste a base de clics arranca protegida. Una tabla que llegó por un archivo de migración, un supabase db push, un fragmento en el SQL Editor o una sentencia que tu constructor de IA ejecutó por ti arranca abierta.

Esa segunda vía es como crea tablas un constructor de IA. Escribe el SQL y lo ejecuta por ti, así que nunca viste la casilla y nunca la viste sin marcar.

La costumbre que lo cierra es poner la línea en la migración, al lado de lo que protege:

create table public.profiles (
  id uuid primary key references auth.users,
  full_name text
);

alter table public.profiles enable row level security;

Cómo comprobar las tablas que el advisor dio por buenas

Hazle a tu base de datos la pregunta que hace un desconocido: manda una petición desde fuera, con la clave publicable que viaja dentro de tu app, y mira qué vuelve.

Esta es la diferencia sobre la que gira todo el artículo. El advisor lee tu configuración. Una petición lee tus filas. Son dos preguntas distintas, y una tabla puede aprobar la primera y suspender la segunda, que es exactamente lo que hace una política de lectura permisiva.

Hicimos esa petición a gran escala. Entre el 12 y el 14 de agosto de 2026 pasamos nueve comprobaciones externas a 30.998 apps en producción publicadas desde Lovable, Base44, Replit, v0 y Bolt. De las 3.680 apps con Supabase donde la comprobación pudo completarse, 2.096 tenían al menos una tabla que respondió con filas a una petición anónima. Eso es un 57 %, y es una proporción de las apps de las que pudimos obtener una respuesta clara, no de todo lo que escaneamos. Entre las apps hechas con Bolt fueron 27 de 35, una muestra lo bastante pequeña como para leerla como una dirección y no como una tasa. El conjunto de datos completo está publicado, y de qué es proporción ese 57 % repasa el recuento.

Puedes hacer tú mismo esa petición contra una tabla con un navegador y tu propia clave publicable. Si prefieres no ir tabla por tabla, nuestro escaneo gratuito le pregunta a tu app en producción desde fuera y te dice qué tablas respondieron. Tarda unos 20 segundos y no necesita cuenta: escanea tu app.

¿Necesito una copia de seguridad antes de cambiar políticas de RLS?

Para cualquier tabla en la que tu app escriba, sí. Para una tabla de solo lectura que solo estás cerrando, el riesgo es que tu app se quede en blanco, no que se pierdan datos.

Aquí conviene separar dos cosas distintas, porque solo una tiene que ver con el arreglo.

Lo que una política permisiva ya permitió. Si la regla de la tabla era FOR ALL USING (true) en vez de FOR SELECT, entonces quien la encontrara podía cambiar y borrar filas además de leerlas, y cerrarla hoy no hace nada respecto a ayer. Esa versión suele aparecer como un mensaje de soporte sobre datos que cambiaron solos, o como una tabla que de pronto está vacía.

El arreglo en sí. Reescribir políticas en una docena de tablas es un cambio sobre una base de datos en producción, escrito por las mismas herramientas que provocaron el problema. Una migración que borra una política y la vuelve a crear mal es un martes cualquiera, y el camino de vuelta es una copia de cómo estaba todo hace una hora.

En un plan de pago de Supabase tienes la copia de anoche en la consola. En el plan gratuito no hay nada a lo que volver, porque el plan gratuito no hace ninguna copia automática. Si ese es tu caso, haz una antes de tocar una política: cómo respaldar una base de datos de Supabase en el plan gratuito es la versión de diez minutos.

De qué guarda una copia Reeve Care

De tu base de datos de Supabase, copiada según un calendario, guardada fuera de tu cuenta de Supabase, cifrada y releída antes de que la fecha de tu panel se mueva. Los archivos que subieron tus usuarios viajan con ella en cuanto conectas una clave de Storage.

Dos límites, dichos por delante. Las copias son solo de Supabase: si tus datos viven en otro sitio lo decimos, en vez de venderte una suscripción que vigila una caja vacía. Y la clave de Storage se pide aparte, porque Supabase no emite una clave de solo lectura para archivos, así que la que copia tus subidas también puede escribir. La que copia tu base de datos no. Conectarla es opcional, y la base de datos se respalda igual.

La restauración es la parte que importa para este artículo. Poner una copia antigua encima de una base de datos en producción es el botón que más miedo da del producto, así que Care copia primero el estado actual y solo después reproduce el que elegiste. La restauración tiene su propio deshacer.

La otra mitad de Care es a la que este artículo lleva apuntando. Una política que se aflojó durante una migración no es algo que encuentres mirando, así que la misma comprobación externa se repite según un calendario y te avisa cuando cambia la respuesta. El uptime, un informe mensual y el escaneo van en la misma suscripción.

Lo que una copia no hace es escribir tus políticas, y ninguna copia convierte una tabla abierta en cerrada. Esas tablas siguen siendo cosa tuya. Lo que cambia la copia es lo que pasa cuando el arreglo sale torcido. Qué respalda Reeve en Supabase, cada cuánto y qué hace una restauración dibuja el ciclo entero, y los planes y sus precios están en la página de precios.

Qué hacer esta semana

Empieza por la tabla que más vergüenza te daría como página pública. La lista de seguridad en 10 minutos cubre esto junto con el resto de lo que conviene comprobar en una app recién lanzada, y la guía de seguridad de Supabase repasa qué más suele quedarse abierto.