¿Tu app hecha con IA está filtrando datos? Una revisión de Supabase en 10 minutos

Las apps hechas con Lovable, Bolt o herramientas similares suelen guardar sus datos en Supabase. Es una buena elección: Supabase es una base de datos Postgres real con autenticación integrada. Pero trae una regla que las herramientas de IA no siempre siguen, y cuando la omiten, cualquiera que abra las herramientas de desarrollo del navegador puede leer los datos de la app.

Esta guía muestra cómo revisar tu propia app en unos diez minutos, sin instalar nada.

Por qué la clave de tu app es pública #

Tu app se comunica con Supabase desde el navegador, así que el navegador necesita una clave. Esa clave, llamada anon key (o publishable key en los proyectos más nuevos), va dentro del JavaScript de tu app. Cualquiera puede encontrarla. Es así por diseño.

Lo que protege tus datos no es la clave, sino Row Level Security (RLS): reglas en la base de datos que deciden qué filas puede leer o cambiar cada visitante. Con RLS activado y buenas reglas, una clave pública es inofensiva. Con RLS desactivado, la clave pública lee la tabla entera.

Paso 1: lista las tablas sin RLS #

Abre tu proyecto en el panel de Supabase, ve al SQL Editor y ejecuta:

select c.relname as table_name,
       c.relrowsecurity as rls_enabled
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind = 'r'
order by c.relrowsecurity, c.relname;

Cada fila con rls_enabled = false es una tabla a la que llega la clave pública. Las tablas creadas en el Table Editor tienen RLS activado por defecto; las creadas con SQL, que es como las crean la mayoría de las herramientas de IA, no.

El Security Advisor del panel marca el mismo problema como RLS Disabled in Public. Si muestra errores, empieza por ahí.

Paso 2: busca reglas que lo permiten todo #

Un RLS activado pero demasiado generoso deja todo igual de abierto. Lista tus reglas:

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
order by tablename, cmd;

Revisa con atención las reglas en las que qual o with_check es simplemente true, sobre todo para los roles anon o public. Una regla así en una tabla profiles u orders significa que cualquiera puede leer todos los perfiles o todos los pedidos.

Paso 3: compruébalo desde fuera #

Ahora pruébalo como lo haría un atacante: solo con la clave pública. Busca la URL del proyecto y la clave en Project Settings → API y ejecuta:

curl "https://TU-PROYECTO.supabase.co/rest/v1/profiles?select=*&limit=5" \
  -H "apikey: TU_CLAVE_PUBLICA"

Cómo leer la respuesta:

• Filas que no son tuyas: la tabla está expuesta. Corrígela hoy.
• Una lista vacía []: o la tabla está vacía, o RLS está filtrando todo, que es lo que quieres.
• Un error de permisos: la tabla no es accesible desde la API. También está bien.

Repite con cada tabla que guarde datos personales, pagos o cualquier cosa privada.

Paso 4: asegúrate de que la clave secreta no está en tu app #

Supabase también te da una service role key (o secret key, que empieza por sb_secret_). Ignora RLS por completo y solo debe vivir en un servidor. Abre tu app publicada, pulsa F12, ve a Sources y busca en el JavaScript service_role y sb_secret_. Si aparece cualquiera de las dos, rota la clave en el panel de inmediato y mueve el código que la necesitaba a una función en el servidor.

Qué corregir primero #

1. Rota cualquier clave secreta que haya llegado al navegador.
2. Activa RLS en todas las tablas del esquema public: alter table public.profiles enable row level security;
3. Sustituye las reglas using (true) de las tablas privadas por reglas basadas en el usuario que inició sesión.
4. Vuelve a ejecutar el Paso 3 y confirma que un desconocido no recibe nada.

Activar RLS romperá cualquier pantalla que dependiera de la tabla abierta. Es lo esperado: cada pantalla necesita ahora una regla que permita exactamente lo que debe. Si tu app la generó una IA y no sabes qué reglas necesita, ese es justo el trabajo con el que empieza nuestro Security Check.