Reglas de acceso en Supabase y Firebase (CWE-862): cómo la falta de Row Level Security expone datos y cómo corregirlo

Conceptos Clave y Términos

Clave anon pública

La clave anon de Supabase y la configuración web de Firebase van dentro del paquete de la app, y cualquiera puede copiarlas. Identifican el proyecto, no al usuario, así que no son secretas ni protegen datos por sí solas.

Row Level Security (RLS)

Una función de PostgreSQL que filtra cada consulta mediante políticas. El Table Editor de Supabase la activa en las tablas nuevas, pero las tablas creadas con SQL o migraciones empiezan con la RLS desactivada, y los permisos por defecto dejan que anon y authenticated lean y modifiquen todas las filas.

USING y WITH CHECK

USING decide qué filas existentes puede ver, actualizar o borrar un usuario; WITH CHECK decide qué filas nuevas o modificadas puede escribir. Una política con solo USING en insert o update permite escribir filas de otra organización.

Clave service_role

La clave service_role se salta la RLS por completo. Solo debe estar en servidores y edge functions, nunca en un navegador ni en una app móvil.

Reglas de Firestore en modo de prueba

Los proyectos iniciados en modo de prueba reciben reglas que permiten todas las lecturas y escrituras hasta una fecha, y muchos acaban cambiándolas a allow read, write: if true. Las reglas deben comparar request.auth.uid con el campo de propietario del documento.

Flujo de Ataque Paso a Paso

Código Fuente: Vulnerable vs. Seguro

-- migration.sql: la RLS nunca se activa en esta tabla
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- la clave anon pública puede leer, modificar y borrar todas las filas
grant select, insert, update, delete on public.invoices to anon, authenticated;

-- migration.sql: RLS activada, anon revocado, una política por comando
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- con la RLS activada, sin política no hay acceso
alter table public.invoices enable row level security;
revoke all on public.invoices from anon;

-- los usuarios solo ven facturas de las organizaciones a las que pertenecen
create policy "members read their org's invoices"
  on public.invoices for select to authenticated
  using (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

-- las filas nuevas deben ser de una organización del usuario; sin políticas de update ni delete
create policy "members add invoices to their org"
  on public.invoices for insert to authenticated
  with check (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

Lista de Verificación de Seguridad para Ingeniería

• Activa la RLS en todas las tablas de los esquemas expuestos y haz fallar la CI cuando select tablename from pg_tables where schemaname = 'public' and not rowsecurity devuelva alguna fila.
• Escribe una política por comando, limitada to authenticated, con USING para las lecturas y WITH CHECK para inserts y updates; no crees políticas de update o delete que no necesites.
• Revoca los permisos de la tabla a anon cuando los usuarios anónimos no tengan motivo para leer, y guarda la clave service_role solo en entornos de servidor.
• Activa la RLS en las tablas que leen tus políticas, como memberships, para que los usuarios no puedan añadirse a otra organización.
• Prueba con dos usuarios de prueba: el usuario A debe recibir cero filas de la organización del usuario B; en Firestore, ejecuta pruebas unitarias de reglas contra el emulador con @firebase/rules-unit-testing.

Fuentes

• CWE-862: Missing Authorization
• Supabase docs — Row Level Security
• PostgreSQL docs — CREATE POLICY
• Firebase docs — Get started with Cloud Firestore Security Rules
• NVD — CVE-2025-48757 (missing Row Level Security in generated apps)