La autorización de API falla silenciosamente: prueba cada objeto, rol y acción

En resumen: La autenticación demuestra quién realizó una solicitud; la autorización determina qué puede hacer esa identidad. La seguridad de una API falla cuando los equipos comprueban la primera cuestión y dan por hecho que la segunda funciona en todas partes.

Un token válido no es un permiso

Las API modernas suelen anteponer una autenticación robusta a controles débiles a nivel de objeto. Una solicitud puede incluir una sesión o un token de acceso perfectamente válidos y, aun así, pedir la factura, el proyecto o la exportación de otro cliente, o solicitar una acción administrativa. Si el controlador solo comprueba que el solicitante ha iniciado sesión, la API ha respondido a la pregunta de seguridad equivocada.

Este fallo es fácil de pasar por alto porque las pruebas habituales del producto siguen el flujo previsto. El propietario abre su propio registro, un administrador utiliza un endpoint de administrador y cada solicitud se completa exactamente como se esperaba. Los defectos de autorización solo aparecen cuando se produce deliberadamente una discrepancia entre la identidad, el objeto, el tenant o la acción.

Crea una matriz de autorización completa

• Prueba cada operación sobre objetos como propietario, como usuario del mismo nivel en el mismo tenant, como usuario de otro tenant y como solicitante no autenticado.
• Comprueba de forma independiente las acciones de lectura, creación, actualización, eliminación, exportación, invitación y aprobación; que un método esté protegido no demuestra que los demás también lo estén.
• Modifica los identificadores en rutas, parámetros de consulta, cuerpos JSON, encabezados y objetos anidados, en lugar de probar únicamente el campo obvio de la URL.
• Verifica las transiciones de roles y las sesiones obsoletas para que los usuarios degradados o eliminados no puedan conservar privilegios mediante claims almacenados en caché.

Deniega por defecto en el límite de los datos

El diseño más fiable vincula cada consulta tanto al objeto solicitado como al ámbito autorizado del solicitante. Recuperar un registro por su identificador y comprobar después la propiedad deja margen para controles olvidados, canales laterales y una gestión de errores incoherente. Consultar dentro de los límites del tenant o de la propiedad integra la condición segura en la propia recuperación.

Los asistentes de políticas centralizados reducen las divergencias, pero no sustituyen a las pruebas. Cada endpoint sigue necesitando aserciones negativas que demuestren que las identidades no autorizadas no reciben datos ni provocan cambios de estado. Una respuesta 403 solo constituye una prueba útil cuando la base de datos y los efectos secundarios posteriores permanecen intactos.

Las pruebas deben demostrar que la ruta prohibida permaneció cerrada

Una prueba de autorización útil registra el solicitante, el rol, el tenant, el objeto de destino, la solicitud, la respuesta y el estado posterior a la solicitud. Estas pruebas permiten distinguir un control real de una restricción en el front-end o de un código de estado que oculta una acción que ya se ha producido.

KENSAI aborda la validación del control de acceso como una matriz, no como un único escaneo del flujo esperado. El objetivo es demostrar el aislamiento entre identidades y acciones, y conservar después pruebas suficientes para reproducir cualquier fallo en los límites y verificar su corrección.

Conclusión

La autorización es una relación entre una identidad, un objeto y una acción. Prueba las tres dimensiones con casos negativos y demuestra que las solicitudes prohibidas no producen exposición de datos ni efectos secundarios.