SANTA-IA
Clase 05 · Seguridad

Que cada usuario vea solo lo suyo: RLS y validación

conceptual
01

Cada usuario ve solo lo suyo

El fallo más caro en un SaaS: que un cliente vea datos de otro. Vamos a evitarlo.

02

RLS: cada quien ve lo suyo

La base de datos misma rechaza acceso ajeno. En Supabase está apagado por defecto. Lo enciendes en cada tabla. Sin RLS, todo queda abierto.

CADA USUARIO SOLO VE SUS FILAS AUSUARIO Apide sus datosdame mis datosBASE DE DATOSRLS ONAfila del usuario ABfila del usuario BAotra fila de ACfila del usuario CBotra fila de Bfiltra por dueñoLO QUE VE AAfila del usuario AAotra fila de Afila de B · bloqueadafila de C · bloqueadafila de B · bloqueadasolo sus dos filas lo impide la base de datos, no el código En Supabase viene apagado por defecto. Hay que encenderlo en cada tabla.
La regla vive en la base de datos. Aunque la app falle, las filas de los demás siguen cerradas.
03

Las llaves caras no van al navegador

NEXT_PUBLIC_ va al navegador. Las llaves de OpenAI, Claude, servicio role: se quedan en el servidor. El prefijo te dice qué es seguro exponer.

DÓNDE VIVE CADA LLAVE NAVEGADORel lado público, lo que todos venNEXT_PUBLIC_SUPABASE_ANON_KEY la anon key de Supabase. Hecha para mostrarse.segura de mostrar AQUÍ TERMINA LO PÚBLICO solo lo marcado NEXT_PUBLIC_ sube sin prefijo, no cruzan SERVIDORel lado escondido, nadie lo ve desde fueraOPENAI_API_KEYcara · se queda aquíANTHROPIC_API_KEYcara · se queda aquíSUPABASE_SERVICE_ROLE_KEYcara · se queda aquí
El prefijo NEXT_PUBLIC_ es el permiso para salir. Sin él, la llave se queda en el servidor.
04

No te fíes de lo que entra

Todo input se valida antes de usarse: tipo, forma, límites. En DS-FORGE lo hace Zod. En vivo no hay revisión de tipos: solo validación real cuenta.

05

Las reglas de la casa

No llaves en el navegador, RLS en cada tabla, todo input validado. El sistema revisa esto por ti. Tu trabajo es entender el porqué.

Volver a Seguridad

hecho con mucho amor

espero les sea útil

santa-ia · 2026 · @santaia.lab