Anon Key con Permisos Excesivos

El rol de base de datos anon tiene permisos en demasiadas tablas, expandiendo la superficie de ataque para cualquiera con la anon key públicamente disponible.

Cómo Funciona

La anon key de Supabase se mapea al rol PostgreSQL anon. Por default este rol tiene permisos limitados, pero los devs frecuentemente le dan acceso a muchas tablas por conveniencia. Como la anon key es pública (embebida en JavaScript del cliente), permisos excesivos en tablas significan que un atacante con solo la anon key y URL del proyecto puede consultar tablas que solo deberían ser accesibles a usuarios autenticados o código del servidor. Incluso con RLS, dar acceso anon a tablas sensibles incrementa el riesgo de mala configuración de políticas.

Código Vulnerable

-- Granting anon access to everything
GRANT ALL ON ALL TABLES IN SCHEMA public TO anon;
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO anon;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO anon;

Código Seguro

-- Only grant anon access to specific public tables
GRANT SELECT ON public.blog_posts TO anon;
GRANT SELECT ON public.categories TO anon;
-- Authenticated users get more access
GRANT ALL ON public.profiles TO authenticated;
GRANT ALL ON public.documents TO authenticated;
GRANT ALL ON public.user_settings TO authenticated;

Ejemplo Real

Las auditorías de seguridad de proyectos Supabase frecuentemente revelan que el rol anon tiene permisos ALL en cada tabla. Combinado con un solo descuido de política USING(true), este patrón ha llevado a exposición completa de bases de datos en aplicaciones en producción.

Cómo Prevenirlo

Solo otorga al rol anon SELECT en tablas intencionalmente públicas
Usa el rol authenticated para acceso a datos específicos del usuario
Audita permisos de roles con: SELECT * FROM information_schema.role_table_grants
Sigue el principio de menor privilegio para todos los roles de base de datos

Tecnologías Afectadas

SupabaseNode.jsNext.jsReact

Data Hogo detecta esta vulnerabilidad automáticamente.

Escanea Tu Repo Gratis

Vulnerabilidades Relacionadas

Row Level Security Deshabilitado

critical

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

CWE-862

Política RLS con USING(true)

critical

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.

CWE-862

RLS Habilitado Sin Políticas

high

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.

CWE-862

Service Role Key Expuesta

critical

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

CWE-798