Supabase cambia el 30 de octubre: qué se rompe y qué sigue expuesto

El 30 de octubre de 2026 Supabase deja de exponer automáticamente en su API las tablas nuevas del esquema public en todos los proyectos existentes. Desde ese día, una tabla creada sin permisos explícitos devuelve un error 42501 a tu app. Las tablas que ya tienes no cambian: conservan sus permisos, y si no tienen RLS activado siguen siendo legibles y modificables por cualquiera que tenga la clave pública de tu proyecto, que está en el código de tu web.

Son dos problemas distintos con la misma causa: los permisos de la base de datos se dejaron en manos de los valores por defecto. Te contamos qué cambia, a quién le afecta y cómo revisarlo en una tarde.

Qué cambia exactamente

Hasta ahora, cada tabla nueva en public recibía permisos de lectura, inserción, actualización y borrado para los roles anon, authenticated y service_role. La API de datos (la que usa supabase-js, PostgREST y GraphQL) podía verla nada más crearla.

Según el anuncio oficial de Supabase, las tablas nuevas ya no reciben esos permisos. Las fechas:

• 30 de mayo de 2026: es el comportamiento por defecto en los proyectos nuevos.
• 30 de octubre de 2026: se aplica a todos los proyectos existentes.

Una tabla creada después de esa fecha sin un GRANT explícito no existe para la API. Las peticiones fallan con permission denied for table y el código 42501. Las tablas anteriores conservan sus permisos y siguen funcionando igual.

Si tu app la generó una IA, esto te afecta más

El anuncio lo dice con todas las letras: afecta a los proyectos que crean tablas en public "mediante migraciones, scripts, la Management API o herramientas de IA" sin permisos explícitos. Es justo como trabajan Lovable, Bolt o un agente en Cursor: piden una tabla, la crean y la app la usa en el momento.

A partir del 30 de octubre, la próxima funcionalidad que pidas puede crear su tabla y fallar en producción, mientras la herramienta te dice que todo ha ido bien. El síntoma típico: una pantalla vacía o un formulario que no guarda, y un 42501 en la consola del navegador.

No te afecta si tu app se conecta a Postgres directamente (con un ORM o una cadena de conexión), ni a las tablas de los esquemas auth, storage, realtime o los esquemas propios.

Lo que no cambia: las tablas que ya están expuestas

Esta es la parte que nos preocupa más. La documentación de seguridad de Supabase es clara: una tabla en un esquema expuesto sin RLS se puede leer y modificar desde cualquier rol que tenga permisos sobre ella. Con los valores antiguos, eso incluye al rol anon, es decir, a cualquiera con la clave pública de tu proyecto.

No es un riesgo teórico. En 2025 se registró la CVE-2025-48757: políticas de RLS insuficientes en apps generadas con Lovable permitían a atacantes sin autenticar leer y escribir en tablas arbitrarias. Lovable la disputa, con el argumento de que cada cliente responde de proteger los datos de su app. Y ese es el punto: la responsabilidad es tuya, la herramienta no la asume.

El cambio del 30 de octubre no arregla nada de esto. Solo hace que las tablas nuevas nazcan cerradas.

Cómo revisarlo en una tarde

Abre el SQL Editor de tu proyecto y haz estas tres comprobaciones.

1. Tablas de public sin RLS. Cada fila de este resultado es una tabla abierta:

select tablename
from pg_tables
where schemaname = 'public' and not rowsecurity;

2. Qué puede hacer el rol anónimo. Mira qué permisos tiene anon en cada tabla:

select table_name, privilege_type
from information_schema.role_table_grants
where grantee = 'anon' and table_schema = 'public'
order by table_name;

Si anon puede hacer INSERT, UPDATE o DELETE en una tabla que tu web no necesita escribir sin sesión iniciada, quítalo.

3. Activa RLS y escribe las políticas. Al activarlo, Supabase bloquea todo el acceso con la clave pública hasta que crees políticas. Hazlo primero en un entorno de pruebas, porque la app dejará de ver los datos hasta entonces:

alter table public.pedidos enable row level security;

create policy "cada usuario ve sus pedidos"
on public.pedidos for select
to authenticated
using (auth.uid() = user_id);

Supabase también marca estas tablas en el Security Advisor y en el Table Editor, con el SQL para corregirlas. Úsalos como segunda opinión, no como única revisión: no saben qué datos son sensibles en tu negocio.

Prepara las tablas nuevas antes del 30

Para que la próxima funcionalidad no falle, cada migración que cree una tabla debe llevar sus permisos y su RLS en el mismo fichero. Es lo que recomienda el propio anuncio:

create table public.facturas ( ... );

alter table public.facturas enable row level security;

grant select, insert, update, delete on public.facturas to authenticated;
grant select, insert, update, delete on public.facturas to service_role;

Da a cada rol solo lo que necesita. Si una tabla no se lee sin iniciar sesión, no le des nada a anon.

Si generas el código con IA, añade esta regla a las instrucciones del proyecto ("cada tabla nueva lleva RLS, políticas y GRANT explícitos en la misma migración") y revisa las migraciones antes de aplicarlas en producción. Puedes adelantar el cambio hoy mismo con las dos sentencias alter default privileges que da el anuncio, y así los fallos aparecen ahora, mientras miras, y no un viernes por la noche.

Una última comprobación: la clave service_role (o la clave secreta) salta el RLS por completo. Supabase insiste en que nunca debe usarse en el navegador. Busca en el código de tu web cualquier clave que no sea la pública.

Lo que hacemos nosotros

Cuando revisamos una app, la base de datos es lo primero que miramos, porque es donde una fuga hace más daño. En una auditoría de una plataforma de empleo encontramos y corregimos 72 problemas de seguridad. Si esas tablas guardan datos de personas, una fuga es además un problema de RGPD, que se aplica a cualquier dato que identifique a alguien (lo explicamos en el post sobre scraping legal en la UE).

En resumen

• Desde el 30 de octubre, las tablas nuevas de public no se ven en la API sin un GRANT explícito. Si no lo pones, tu app falla con 42501.
• Las tablas existentes no cambian. Si no tienen RLS, siguen abiertas a cualquiera con la clave pública.
• Revisa hoy las tablas sin RLS y los permisos de anon con las dos consultas de arriba.
• Pon RLS, políticas y permisos en la misma migración que crea cada tabla.
• La clave service_role nunca va en el navegador.

Si has construido tu app con IA y no sabes cómo está su base de datos, cuéntanos qué has construido. La revisamos en una semana y te decimos qué es urgente y qué puede esperar.