Row Level Security (RLS)

Qué significa “Row Level Security (RLS)” (explicación simple)

Row Level Security (RLS) . 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 Row Level Security (RLS) en Supabase

En Postgres, Row Level Security (RLS) hace que el motor evalúe una condición por fila antes de permitir SELECT/INSERT/UPDATE/DELETE. En Supabase, esto se combina con roles como anon/authenticated y con el contexto del JWT. El problema típico no es “tener o no tener políticas”, sino si RLS está realmente activado/forzado y si las políticas limitan filas por usuario/tenant. Un frontend puede ocultar datos, pero si la base permite consultas directas, un atacante usará la API (PostgREST) y saltará tu UI.

Rutas de ataque y fallos comunes (Row Level Security (RLS))

• RLS está desactivado: las políticas no se aplican (aunque “existan” en el dashboard).
• RLS está activado pero no forzado: ciertos roles privilegiados pueden saltárselo.
• Políticas demasiado amplias (no vinculan la fila a un usuario o tenant).
• Grants permiten lectura/escritura a anon/authenticated en tablas sensibles.
• La autorización vive solo en la UI y se puede bypass con llamadas directas.

Dónde mirar en tu proyecto (Supabase)

• Estado de RLS por tabla (activado/forzado) y cambios entre entornos.
• Expresiones de políticas (¿realmente restringen por auth.uid() o por membresía/tenant?).
• Grants a anon/authenticated y a PUBLIC en tablas, vistas y funciones relacionadas.
• Rutas del frontend que consultan tablas directamente (REST o SDK).

Cómo suele fallar Row Level Security (RLS) en Supabase

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

• Believing a table is protected because a policy exists even though RLS is disabled or not forced.
• Leaving broad SELECT/UPDATE grants on anon or authenticated while assuming policies will override them.
• Trusting client-side filtering instead of letting the database enforce row-level restrictions.

Cómo detectar problemas de Row Level Security (RLS)

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

• Intenta un SELECT directo con credenciales de cliente y verifica si devuelve filas.
• Comprueba si RLS está activado y si aplica, forzado, en tablas sensibles.
• Revisa políticas que usan condiciones genéricas o “siempre true”.
• Confirma que el acceso “autenticado” no equivale a “autorizado”.
• Repite pruebas después de migraciones (drift).

Cómo corregir Row Level Security (RLS) (enfoque backend-only)

1. Mueve operaciones sensibles a endpoints del backend con autorización explícita.
2. Revoca grants directos a anon/authenticated en tablas y funciones sensibles.
3. Activa y fuerza RLS en tablas donde sea relevante como safety gate.
4. Elimina políticas amplias y adopta un posture deny-by-default cuando puedas.
5. Verifica con pruebas directas: el acceso desde el cliente debe fallar.
6. Re-escanea y documenta la regla para evitar regresiones.

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

1. Repite exactamente la misma llamada directa (REST) y confirma 401/403.
2. Comprueba que el backend sigue funcionando para usuarios autorizados.
3. Asegura que staging/prod tienen la misma configuración (sin drift).
4. Vuelve a listar políticas/grants y confirma que no reaparecieron accesos amplios.
5. Repite el escaneo o checklist después de la siguiente migración.

Prevención de drift (para que no vuelva)

• Añade un checklist en releases: nuevas tablas con RLS desactivado, nuevas políticas amplias, grants a client roles.
• Evita depender de lógica de autorización en la UI; prioriza backend-only para datos sensibles.
• Haz revisión obligatoria de políticas/grants en PRs y migraciones.

Ejemplos y por qué funcionan

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

• RLS missing exposes user profiles → /examples/row-level-security/rls-missing-exposes-profiles — Disabled RLS let the public profiles table leak every profile even though the UI hid it.
• RLS enabled but not forced → /examples/row-level-security/rls-enabled-but-not-forced — RLS was enabled but not forced, letting privileged paths bypass the filters.

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

Enlaces relacionados (English canonical + templates)

• English canonical: Row Level Security (RLS) → /glossary/row-level-security

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 ქართული. 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.