criticalCWE-862

Política RLS con USING(true)

Las 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.

Cómo Funciona

Los devs frecuentemente habilitan RLS pero luego crean políticas demasiado permisivas para que las cosas funcionen rápido. Una política como USING(true) da acceso a cada fila para cada usuario, incluyendo anónimos. Esto es funcionalmente equivalente a tener RLS deshabilitado. Crea una falsa sensación de seguridad porque el badge de RLS aparece habilitado en el Dashboard de Supabase, pero no se aplica filtrado real. Los atacantes pueden consultar, modificar o eliminar cualquier fila de la tabla.

Código Vulnerable
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;

CREATE POLICY "allow_all" ON public.profiles
  FOR ALL
  USING (true)
  WITH CHECK (true);
Código Seguro
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;

CREATE POLICY "users_read_own" ON public.profiles
  FOR SELECT USING (auth.uid() = id);
CREATE POLICY "users_update_own" ON public.profiles
  FOR UPDATE USING (auth.uid() = id)
  WITH CHECK (auth.uid() = id);

Ejemplo Real

En 2024, una herramienta SaaS popular fue encontrada con políticas USING(true) en sus tablas de datos de clientes. Un atacante usó la anon key pública para consultar todos los registros de clientes a través del cliente Supabase, exfiltrando miles de registros de negocio antes de que el problema fuera parcheado.

Cómo Prevenirlo

  • Nunca uses USING(true) excepto en tablas intencionalmente públicas de solo lectura
  • Siempre limita las políticas a auth.uid() para datos del usuario
  • Separa políticas SELECT, INSERT, UPDATE, DELETE para control granular
  • Audita políticas existentes con: SELECT * FROM pg_policies

Tecnologías Afectadas

SupabaseNode.jsNext.jsReact

Data Hogo detecta esta vulnerabilidad automáticamente.

Escanea Tu Repo Gratis

Vulnerabilidades Relacionadas