RLS Habilitado Sin Políticas
RLS está habilitado en una tabla pero no hay políticas definidas, lo que silenciosamente bloquea todo el acceso incluyendo queries legítimos de tu aplicación.
Cómo Funciona
Cuando RLS está habilitado en una tabla de Supabase pero no existen políticas, PostgreSQL por default deniega todo acceso. Esto significa que tu aplicación no puede leer, insertar, actualizar o eliminar filas a través de la librería cliente. Aunque esto es seguro por default, frecuentemente lleva a los devs a bypassear RLS usando la service_role key en el lado del cliente, lo cual es mucho peor. La tabla parece rota, así que los devs o deshabilitan RLS o filtran la service key — ambos errores de seguridad críticos.
-- RLS is on, but no policies exist
ALTER TABLE public.orders ENABLE ROW LEVEL SECURITY;
-- No policies created!
-- Developer "fixes" it by using service_role in the frontend:
const supabase = createClient(url, SERVICE_ROLE_KEY); // DANGER!ALTER TABLE public.orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY "users_read_own_orders" ON public.orders
FOR SELECT USING (auth.uid() = user_id);
CREATE POLICY "users_insert_own_orders" ON public.orders
FOR INSERT WITH CHECK (auth.uid() = user_id);
CREATE POLICY "users_update_own_orders" ON public.orders
FOR UPDATE USING (auth.uid() = user_id);Ejemplo Real
Un patrón común en proyectos Supabase en GitHub: los devs habilitan RLS para satisfacer warnings de linting, pero nunca crean políticas. Cuando su app se rompe, cambian a la service_role key en código del cliente, sin saber que le dan a cada usuario acceso admin completo a la base de datos.
Cómo Prevenirlo
- Siempre crea al menos una política por operación al habilitar RLS
- Prueba las políticas RLS desde el cliente inmediatamente después de escribir migraciones
- Usa Supabase CLI para verificar políticas: supabase db lint
- Nunca uses la service_role key en código del cliente como workaround
Tecnologías Afectadas
Data Hogo detecta esta vulnerabilidad automáticamente.
Escanea Tu Repo GratisVulnerabilidades Relacionadas
Row Level Security Deshabilitado
criticalLas tablas de Supabase sin RLS habilitado permiten a cualquier usuario autenticado o anónimo leer, insertar, actualizar y eliminar todas las filas usando la librería cliente.
Política RLS con USING(true)
criticalLas políticas RLS que usan USING(true) o WITH CHECK(true) efectivamente deshabilitan la seguridad a nivel de fila al permitir todas las operaciones para todos los usuarios.
Service Role Key Expuesta
criticalLa service_role key de Supabase está hardcodeada en código frontend, comiteada en un repo o expuesta en bundles del cliente, dando acceso admin completo a la base de datos a cualquiera.
Buckets de Storage Públicos
mediumLos buckets de storage de Supabase con políticas permisivas permiten a cualquier usuario subir, leer o eliminar archivos incluyendo documentos privados e imágenes de otros usuarios.