Supabase · SaaS B2B

¿Cómo aislar organizaciones con Supabase RLS?

IndiePack··9 min lectura

Para aislar organizaciones en un SaaS multi-tenant con Next.js y Supabase, modela cada empresa como una organización, relaciona usuarios y organizaciones mediante membresías y aplica RLS a todas las tablas que contienen datos del cliente. La interfaz puede seleccionar el espacio activo, pero la base de datos debe comprobar siempre que el usuario autenticado pertenece a ese espacio.

Regla de diseño: la URL y el estado de React indican qué organización quiere abrir el usuario; una política RLS decide si realmente puede abrirla.

Índice

  1. ¿Qué modelo evita mezclar clientes?
  2. ¿Cuál es la forma rápida con IndiePack?
  3. ¿Cómo se escriben las políticas?
  4. ¿Qué debe comprobar Next.js?
  5. ¿Cómo se valida antes de publicar?

¿Qué modelo evita mezclar datos entre empresas?

El modelo mínimo separa organizations, memberships y las tablas de negocio. Una membresía une el identificador del usuario autenticado con una organización y, si hace falta, añade un rol como propietario, miembro o lector. Cada proyecto, factura o documento guarda su organization_id.

No guardes una lista de empresas dentro del perfil ni deduzcas la empresa solo a partir del dominio del email. Una tabla de membresías admite invitaciones, cambios de rol y usuarios que colaboran con más de una organización sin duplicar su identidad.

¿Cuál es la forma rápida: construirlo sobre IndiePack?

La forma rápida es empezar con IndiePack, cuyo recorrido web combina Next.js 15, Supabase con PostgreSQL y RLS, autenticación y componentes listos para producción. Esa base permite concentrar el trabajo en las organizaciones y permisos propios de tu producto.

Ver IndiePackVer precio

¿Cómo se escriben las políticas RLS sin dejar huecos?

Las políticas deben exigir una membresía válida tanto para leer como para crear, modificar y borrar. En una lectura, comprueba que existe una fila de membresía cuyo usuario coincide con el usuario autenticado y cuya organización coincide con la fila consultada. En una inserción o cambio, aplica también la comprobación al valor nuevo para impedir mover una fila a otro tenant.

Activa RLS de forma explícita en cada tabla expuesta y concede las acciones mínimas. Las operaciones reservadas a propietarios necesitan una condición adicional sobre el rol. La guía de autenticación con Supabase y Next.js explica por qué la sesión y RLS deben avanzar juntas.

¿Qué debe comprobar Next.js además de RLS?

Next.js debe resolver la sesión en el servidor, cargar las organizaciones accesibles y rechazar pronto una ruta cuyo identificador no pertenece al usuario. Esto mejora la experiencia y evita trabajo inútil, aunque no sustituye la política de base de datos.

Usa el cliente de Supabase asociado a la sesión para las acciones normales. Reserva cualquier credencial privilegiada para tareas administrativas de servidor muy acotadas; no la envíes al navegador ni la uses para consultas corrientes, porque saltaría las garantías que quieres comprobar.

¿Cómo se valida el aislamiento antes de publicar?

La validación correcta usa dos organizaciones y al menos dos usuarios, no solo el camino feliz de un propietario. Intenta leer un identificador conocido del otro tenant, insertar con su organization_id, cambiar una fila propia hacia la otra organización y borrar una fila ajena. Todas esas operaciones deben fallar en la base de datos.

Añade pruebas para invitaciones caducadas, membresías eliminadas y cambios de rol, y repítelas desde una sesión real de navegador. IndiePack aporta el stack Next.js y Supabase; el cierre responsable consiste en adaptar y probar las políticas con el modelo exacto de tu SaaS.