Over-permissive RLS Policies

Qué significa “Over-permissive RLS Policies” (explicación simple)

Over-permissive RLS Policies . Builders use this concept to reduce accidental exposure and keep sensitive operations behind clear authorization boundaries.

En resumen: si alguien puede acceder al recurso directamente (sin pasar por tu backend), el control real está en la base/Storage/RPC — no en tu UI.

Explicación técnica: cómo funciona Over-permissive RLS Policies en Supabase

RLS puede ser correcto en teoría y peligroso en práctica si las políticas son demasiado permisivas. El fallo más común es confundir autenticación con autorización: permitir a authenticated sin atar filas a ownership o tenant. En apps multi-tenant, una condición mal puesta puede permitir lecturas cruzadas. La forma más robusta de reducir este riesgo es minimizar la superficie de políticas y mover operaciones sensibles al backend.

Rutas de ataque y fallos comunes (Over-permissive RLS Policies)

• Condiciones que siempre evalúan true (acceso prácticamente público).
• Falta de límite por tenant/membresía (lectura cruzada).
• Uso de valores controlados por el cliente en condiciones de política.
• Interacciones inesperadas entre múltiples políticas.
• Cambios de esquema que vuelven obsoletas las políticas y amplían acceso.

Dónde mirar en tu proyecto (Supabase)

• Expresiones de políticas: ¿usan auth.uid() o joins a tablas de membresía?
• Tablas multi-tenant con políticas que no filtran por tenant_id.
• Políticas “temporales” que nunca se eliminaron.
• Casos donde la UI filtra, pero la base no.

Cómo suele fallar Over-permissive RLS Policies en Supabase

Estos son patrones que aparecen una y otra vez en proyectos reales:

• Copying policy snippets that include tautologies or fail to bind rows to auth.uid().
• Treating broad authenticated conditions as safe without tenant or ownership checks.
• Assuming policies protect data while leaving grants untouched.

Cómo detectar problemas de Over-permissive RLS Policies

El objetivo es comprobar el comportamiento real, no lo que “parece” en la UI.

• Prueba acceso como un usuario de otro tenant y confirma que se deniega.
• Revisa políticas que dependen de condiciones complejas difíciles de explicar.
• Busca SELECT permitido a authenticated sin ownership/tenant checks.
• Verifica si RLS está forzado (evita bypass accidental en algunos roles).
• Repite pruebas después de migraciones.

Cómo corregir Over-permissive RLS Policies (enfoque backend-only)

1. Simplifica políticas: preferir checks explícitos de ownership/membresía.
2. Elimina políticas que no entiendes completamente; vuelve a deny-by-default.
3. Mueve operaciones sensibles a endpoints backend y reduce dependencia en RLS.
4. Revoca grants amplios a roles de cliente.
5. Crea tests/reglas para acceso cross-tenant.
6. Verifica con pruebas directas y re-escaneo.

Checklist de verificación (después de corregir)

1. Usuarios fuera de la fila/tenant no pueden leer ni escribir (prueba directa).
2. Políticas son pequeñas y explicables (puedes describir el “quién/qué/por qué”).
3. El cliente ya no depende de políticas amplias para que la UI funcione.
4. Checklist detecta políticas nuevas o cambios amplios.
5. Escaneo confirma reducción de exposición.

Prevención de drift (para que no vuelva)

• Revisión obligatoria de políticas en PRs (como si fueran cambios de auth).
• Preferir backend-only para recursos sensibles y dejar RLS como safety gate.
• Añadir pruebas para escenarios cross-tenant.

Ejemplos y por qué funcionan

Estos ejemplos muestran escenarios concretos, causa raíz y corrección:

• Policy condition always true → /examples/over-permissive-rls-policies/policy-condition-always-true — A copied policy always evaluated true, turning the protected table into a public read.
• Policy missing tenant boundary → /examples/over-permissive-rls-policies/policy-missing-tenant-boundary — The tenant policy only verified login, so every customer’s data bled across tenants.

Úsalos para reconocer el patrón en tu propio esquema y repetir la verificación.

Enlaces relacionados (English canonical + templates)

• English canonical: Over-permissive RLS Policies → /glossary/over-permissive-rls-policies
• Template: Remove over-permissive RLS policies (adopt deny-by-default) → /templates/access-control/remove-over-permissive-policies

Preguntas rápidas (auto‑evaluación)

Si respondes “sí” a cualquiera de estas preguntas, vale la pena priorizar este fix:

• ¿Puedo acceder al recurso con una llamada directa (sin pasar por mi backend)?
• ¿El control de acceso depende de la UI (botones/ocultar pantallas) en lugar de la base/Storage?
• ¿No tengo una verificación repetible que pueda ejecutar tras migraciones?
• ¿Hay diferencias entre dev/staging/prod que podrían reintroducir exposición (drift)?
• ¿Estoy usando políticas/grants amplios por “comodidad” y sin documentación?

El objetivo no es “hacerlo perfecto”; es reducir exposición con un cambio pequeño, verificable y repetible.

Notas culturales/idioma

Esta página está optimizada para consultas en isiZulu. Si necesitas máxima precisión técnica, usa también la página en inglés (canonical).

Resumen rápido (para llevar)

• Valida siempre con acceso directo: los atacantes no usan tu UI.
• Prefiere backend-only para recursos sensibles y usa verificación repetible.
• Después de cada migración, re-ejecuta checks para evitar drift.
• Mantén secretos server-only y revisa grants/políticas/buckets/EXECUTE con disciplina.

Plantilla de “enunciado de límite” (para documentar el fix)

Este enunciado te ayuda a dejar claro el modelo de acceso y a detectar regresiones:

• Solo el backend puede (operación) sobre (recurso) tras autorización explícita.
• El cliente no debe poder acceder directamente a (tabla/bucket/función) con credenciales anon/auth.
• Verificación: la llamada directa (describe la petición) debe fallar en dev/staging/prod.

Guardar este enunciado junto con la evidencia (antes/después) hace que revisiones y migraciones sean más seguras.

Mini ejemplo de verificación (sin SQL)

Si quieres una verificación rápida sin meterte en SQL, usa este enfoque:

1. Antes del fix, intenta una llamada directa desde el cliente (REST/RPC/Storage) y guarda el resultado.
2. Aplica el cambio (backend-only + revocar accesos amplios) y repite la misma llamada directa.
3. Confirma que ahora falla con una denegación clara, y que el backend autorizado sigue funcionando.
4. Repite en staging/prod para evitar el clásico “funciona en dev”.

Si estas cuatro líneas se cumplen, tu corrección es real y resistente a regresiones.

Plan operativo de 7 días (aplícalo sin bloquear producto)

Este plan está pensado para equipos pequeños que necesitan mejorar seguridad sin frenar entregas. La idea es hacer un cambio corto, verificable y repetible cada día, con foco en evidencia y no en teoría.

1. Día 1: identifica el recurso más sensible relacionado con este término y reproduce el riesgo con una llamada directa.
2. Día 2: crea o ajusta la ruta backend-only y documenta la regla de autorización en una frase.
3. Día 3: revoca el acceso directo amplio desde cliente (grants, bucket público o EXECUTE público, según aplique).
4. Día 4: ejecuta verificación en dev y staging con la misma prueba directa; debe fallar de forma consistente.
5. Día 5: repite en producción y guarda evidencia mínima (qué cambió, prueba usada, resultado esperado).
6. Día 6: añade guardrail post-migración (scan o checklist) para evitar drift silencioso.
7. Día 7: revisa una ruta relacionada (tabla, Storage o RPC) y repite el ciclo con menor fricción.

Si mantienes este ritmo semanal, reduces exposición real sin depender de “arreglos heroicos” de último minuto.

Siguiente paso

Si sospechas exposición en tu proyecto, ejecuta un escaneo y valida el acceso directo. Después aplica un template y verifica que el acceso desde el cliente ya no funcione.