Que cada usuario vea solo lo suyo: RLS y validación
conceptualPor qué medio mundo usa Supabase
Supabase te da el backend entero hecho: la base de datos, el inicio de sesión y la puerta para que tu app hable con la base. Arrancas rápido, sin montar un servidor. Por eso lo usa tanta gente.
Y ahí mismo nace su mayor riesgo
Esa comodidad expone tu base hacia afuera, hasta el navegador. Y el guardia viene apagado de fábrica. Si no lo enciendes, cualquiera con la llave pública pide datos de otros clientes. Por eso es lo primero que cierras.
Cada usuario ve solo lo suyo
El fallo más caro en un SaaS: que un cliente vea datos de otro. Vamos a evitarlo.
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.
El caso de Ana y Beto
Una tabla facturas. Sin RLS, si Beto la pide, la base le entrega todo, hasta las de Ana. Con RLS, la base solo le da las suyas. Aunque el código tenga un bug.
El SQL que lo enciende
Dos líneas. La primera prende el guardia en la tabla. La segunda pone la regla: cada quien ve solo las filas con su user_id. auth.uid() lo pone la base, no el cliente.
# 1) Enciende el guardia en la tablaalter table facturas enable row level security;# 2) Regla: cada quien ve solo SUS facturascreate policy "cada quien ve sus facturas"on facturasfor selectusing ( (select auth.uid()) = user_id );El interruptor del panel
Cada tabla trae un botón Enable RLS. La trampa: si la creas por SQL, nace apagada hasta que la enciendes. Una tabla nueva sin guardia es una tabla abierta.
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.
Dos llaves: anon y service_role
La anon (prefijo NEXT_PUBLIC_) va al navegador y respeta RLS. La service_role se salta RLS entera. Esa jamás toca el navegador. Vive solo en el servidor.
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.
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é.