Define la relación entre la persona, el recurso y la acción
Para definir un permiso, identifica quién pide acceso, qué recurso quiere y qué pretende hacer con él. Consultar, modificar y eliminar son decisiones distintas. Añade la relación relevante, como pertenecer a la empresa responsable del documento, para que la regla corresponda al funcionamiento del negocio y pueda verificarse.
Imagina una imprenta con un portal donde los clientes entregan archivos para imprimir. Una persona puede entrar en el portal para seguir su propio trabajo. Eso no significa que pueda abrir archivos de otra empresa, aprobar una prueba en nombre de otro cliente o cambiar la fecha prevista de un pedido.
Incluso dentro de la misma empresa puede haber responsabilidades distintas. Un colaborador envía el archivo, otro confirma la prueba y alguien sigue la entrega. Si el producto necesita esa separación, la aplicación debe expresarla. La palabra cliente, por sí sola, puede resultar demasiado amplia para determinar todas las acciones permitidas.
Empieza escribiendo ejemplos breves de acceso permitido y rechazado. Una persona asociada al pedido puede consultar la prueba; alguien de otra empresa no puede. Si la regla admite una excepción, como acceso del equipo de producción, describe la responsabilidad que la justifica y el alcance de ese acceso.
Estas elecciones pertenecen al trabajo de planificar la aplicación antes de programar. La IA puede ayudar a organizar la matriz de permisos, pero necesita recibir las decisiones del negocio. Sin ellas, puede construir un login funcional y seguir sin saber qué fronteras de información debe respetar después de entrar.
Para preparar el siguiente paso, consulta Seguridad de aplicaciones desarrolladas con IA.
No utilices el menú como prueba de protección
Ocultar un botón o retirar un documento de la lista puede mejorar la presentación, pero no demuestra que el sistema rechace el acceso. La autorización debe existir donde se procesa la solicitud y se entregan los datos. La prueba debe confirmar el rechazo aunque la opción no aparezca en pantalla.
En el portal de la imprenta, la página puede listar solo los pedidos de la empresa correcta. Aun así, hay que comprobar qué ocurre cuando llega al sistema una solicitud relativa a otro registro de prueba. El resultado debe depender de la autorización de la persona sobre ese recurso, no de su presencia en la lista visible.
El identificador de un documento sirve para localizarlo, sin conceder permiso sobre él. Hacerlo difícil de adivinar puede tener utilidad, pero no sustituye la regla de acceso. Un enlace puede circular en un mensaje o quedar guardado en un historial y seguir necesitando una verificación adecuada.
Tampoco aceptes como autoridad una indicación enviada por el propio formulario que diga que la persona es administradora. La aplicación debe obtener identidad y poderes relevantes a partir de información verificada. De lo contrario, la solicitud pasa a decidir una condición que debería controlar quien la recibe.
Aplica la regla a los archivos y los datos relacionados
El permiso sobre una página debe ser coherente con el acceso a los elementos que presenta. Comprueba adjuntos, exportaciones, imágenes privadas y otros recursos vinculados al registro. Proteger la consulta principal deja trabajo pendiente si un archivo asociado puede obtenerse mediante una dirección que no aplica la misma decisión.
En la imprenta, un pedido puede estar correctamente protegido y tener una prueba de impresión guardada en otro servicio. La revisión debe seguir ese archivo hasta la forma en que se pone a disposición. No basta con comprobar que el botón de descarga solo aparece para quien entró en el portal y pertenece a la empresa correcta.
Lo mismo se aplica a una exportación utilizada por el equipo. Define si puede contener todos los pedidos o solo los que corresponden a la responsabilidad de esa persona. Una función de informes puede introducir un acceso distinto del probado en la página individual, aunque utilice los mismos datos de origen.
Al dar contexto a la IA sin información indiscriminada, explica qué datos son privados, quién los necesita y por qué. Los ejemplos ficticios bastan para desarrollar los casos de permisos. No hace falta exponer archivos reales de clientes para demostrar cómo debe funcionar la separación entre dos empresas en el portal.
Confirma las protecciones en las capas que entregan información
La aplicación debe aplicar la autorización en el servidor y proteger el acceso a los datos según la arquitectura utilizada. En proyectos con Supabase, eso incluye comprobar permisos y políticas de la base de datos. Tener activa una opción de seguridad no demuestra que las reglas permitan y rechacen exactamente los casos previstos.
Pide una explicación vinculada al recorrido: dónde se verifica la sesión, dónde se decide la autorización y qué protección existe al consultar el registro. La respuesta debe permitir relacionar la regla del negocio con los controles implementados. Una lista de nombres técnicos sin esa relación es difícil de evaluar.
En los datos, comprueba el efecto de cada operación necesaria. Una regla de lectura correcta no resuelve automáticamente las condiciones para crear o modificar un registro. En el portal, permitir enviar un archivo para un pedido exige confirmar que la persona puede actuar sobre ese pedido, además de aceptar el tipo de archivo.
Las cuentas privilegiadas utilizadas por operaciones merecen atención propia. No deben servir para simular un cliente común y concluir que las restricciones funcionan. Si la prueba se ejecutó con poderes superiores a los del usuario final, la evidencia debe decirlo y la comprobación adecuada sigue pendiente.
Prueba el rechazo con la misma atención que el éxito
Prepara cuentas y registros ficticios que permitan demostrar acceso legítimo e indebido en el entorno autorizado de prueba. Verifica el resultado de la solicitud y los efectos sobre los datos. Un mensaje de error es insuficiente si la información se entregó o el cambio ocurrió antes de mostrar ese mensaje.
Para la imprenta, crea dos clientes de prueba y pedidos separados. Confirma que cada uno ve y modifica solo lo permitido y que el equipo interno tiene el alcance definido. Añade una sesión terminada o alguien cuyo acceso se retiró, según el comportamiento previsto para la gestión de usuarios.
Registra qué versión y configuración se verificaron, evitando presentar una revisión antigua como prueba de un cambio reciente. Igual que al probar una automatización antes de entregarla, el informe debe separar observaciones, hipótesis y asuntos pendientes. La confianza se apoya en el comportamiento demostrado, incluidas las acciones que el sistema rechazó correctamente.
Cuando añadas un nuevo tipo de archivo, informe o acción, vuelve a la regla correspondiente y a las pruebas afectadas. El login puede seguir exactamente igual mientras aparecen posibilidades nuevas de acceso. Esa evolución exige mantener la autorización vinculada a los recursos reales de la aplicación y a las responsabilidades actuales de las personas.