Un estudio de UpGuard sobre unos 300.000 dominios con indicios de usar Supabase ha encontrado 16.326 bases de datos con tablas legibles desde fuera, sin ninguna autenticación de por medio. Más de la mitad expone datos personales identificables, y una parte menor deja a la vista contraseñas, tokens de sesión o, en casos puntuales, datos de pago.
La causa no es un fallo de Supabase como plataforma, sino un hueco entre dos formas de crear tablas. Desde un parche de seguridad de 2025, las tablas creadas desde el Table Editor del panel de Supabase activan Row Level Security (RLS) por defecto. Las tablas creadas por SQL, migraciones o llamadas a la API, no. Y esa segunda vía es exactamente cómo un agente de IA (Cursor, Bolt, Lovable, Claude Code…) monta el backend cuando alguien "vibe-codea" una app: genera el esquema en SQL directamente, sin pasar nunca por el panel.
RLS por defecto solo se activa si creas la tabla a mano en el Dashboard — si nace de un SQL generado por un agente, nadie la protege por ti.
Para quien lea El Rack esto importa aunque no gestione infraestructura de una empresa: un proyecto personal, una prueba de fin de semana montada con un agente de IA, o una instancia propia de Supabase autoalojada en el homelab para probar algo, pueden estar exponiendo datos reales sin que lo sepas — sobre todo si en algún momento le pediste al agente que "cree la tabla de usuarios" y este ejecutó el SQL directamente.
Qué hacer ya: revisa el Security Advisor del propio panel de Supabase, que marca explícitamente las tablas sin RLS activo, y trata cualquier tabla que haya creado un agente por SQL como pública por defecto hasta que compruebes lo contrario — no solo la que hayas tocado tú a mano desde el Dashboard.
Fuentes: techcrunch.com · cybernews.com · unite.ai
