¿Un cliente puede acceder a los datos de otro en tu SaaS?

Dos empresas usan el mismo sistema. Cada una ve su nombre en el encabezado, sus pedidos y sus informes. Parece aislamiento, pero la interfaz solo muestra lo que recibe. La protección debe actuar antes de que el servidor devuelva los datos.

Piensa en una ruta que busca un pedido por su identificador. Si el servidor solo comprueba que existe una sesión, una persona autenticada podría recibir un pedido de otra empresa. Ni siquiera hace falta que la interfaz muestre un botón para abrirlo.

Es una prueba útil antes de añadir informes o una búsqueda con IA. Cada nueva forma de leer datos debe respetar la separación entre clientes.

Resuelve la organización en el servidor

El navegador puede indicar qué organización seleccionó la persona. El servidor debe verificar la sesión, confirmar que pertenece a esa organización y autorizar la acción solicitada. Un identificador enviado en un formulario no demuestra acceso.

La guía de autorización de OWASP recomienda denegar por defecto y comprobar permisos en cada solicitud. Ocultar controles en la interfaz no sustituye esa comprobación.

Después de autorizar la lectura, una consulta parametrizada puede limitar el pedido a la organización verificada:

SELECT id, status, created_at
FROM orders
WHERE organization_id = $1
  AND id = $2;

Aquí, $1 viene del contexto validado en el servidor. $2 es el pedido solicitado. La consulta ilustra el filtro de organización, pero no implementa toda la política de acceso. Un miembro de la empresa podría tener permiso para ver solo sus propios pedidos.

Aplica el mismo razonamiento a modificaciones y eliminaciones. Comprueba las relaciones. Un pedido de la empresa A no debe aceptar una referencia a un cliente de la empresa B solo porque ambos registros existen.

La base de datos puede reforzar la regla

PostgreSQL admite políticas por fila. Los superusuarios y los roles con BYPASSRLS las omiten. El propietario de la tabla normalmente también, salvo cuando se aplica FORCE ROW LEVEL SECURITY.

Si adoptas esta función, prueba con el rol que usa la aplicación en producción. Una prueba como administrador puede dar una impresión equivocada de la protección. Comprueba qué contexto de organización llega a la base y cómo termina tras cada operación.

En conexiones reutilizadas, recomendamos pasar el contexto dentro de una transacción y limitar su duración a ella. El trabajo siguiente no debe heredar la organización anterior. La ausencia de contexto debe impedir el acceso y necesita su propia prueba.

Busca las salidas que no pasan por la lista

Un sistema puede proteger la consulta de pedidos y filtrar datos mediante un informe exportado. Haz un inventario de los caminos que entregan información al usuario.

La clave de caché debe distinguir la organización y el alcance de acceso relevante. Un acierto en caché también debe respetar la autorización actual. Para los archivos, comprueba el acceso antes de emitir un enlace temporal de descarga.

En una tarea en segundo plano, registra la organización y la identidad responsable. Define si usa el permiso actual del solicitante o un permiso de servicio explícito. Eliminar a una persona de una empresa no debe dejar esa decisión al azar.

Incluye la búsqueda con IA en la revisión. Filtra los documentos autorizados antes de enviarlos al modelo. Pedirle que no revele datos de otros clientes no corrige una consulta que ya los recuperó.

Prueba siempre con dos empresas

Crea datos ficticios para dos organizaciones. Ejecuta la misma operación con un usuario de cada una e intenta cruzar los identificadores. Incluye lecturas, escrituras y descargas.

Repite una consulta después de que la otra organización haya llenado la caché. Prueba una tarea creada antes de eliminar a un usuario. Comprueba también una solicitud sin contexto de organización. Son casos que una prueba de inicio de sesión no cubre.

El resultado esperado incluye el efecto en el almacenamiento. Rechazar la respuesta después de guardar un cambio indebido no basta.

Antes de publicar la próxima función, enumera los datos que lee y los caminos por los que salen. Recorre esa lista como usuario de la otra empresa. Esa prueba dice más que el nombre correcto en el encabezado.