Pruebas de regresión de autorización

Una prueba de regresión de autorización recorre la matriz y, para cada celda, entra con una cuenta de ese rol, pide esa acción y comprueba el resultado esperado. Lo que la hace útil está en tres detalles. Primero, prueba también los casos negativos: que el contratista reciba 403 al aprobar un pago vale tanto como que la gerencia financiera reciba 200, porque la mayoría de los fallos de autorización son permisos de más, no de menos. Segundo, prueba con al menos dos cuentas del mismo rol sobre objetos distintos, porque el IDOR es un fallo entre iguales que una sola cuenta por rol no puede ver. Tercero, falla cuando una ruta desplegada no tiene caso: una ruta sin prueba es una ruta que nadie decidió.

La guía de pruebas web de OWASP (WSTG) trata la autorización en su propia sección, con pruebas de saltos del esquema de autorización y de escalada de privilegios. La matriz es lo que vuelve esas pruebas repetibles en cada cambio en lugar de hacerlas una vez al año.

Abre prueba_autorizacion.py y lee cómo construye la lista de casos a partir de matriz.csv. Compara después cuántas filas tiene la matriz con cuántos casos dice resultado-ci.txt que se ejecutaron.

La prueba de rutas sin caso existe, pero imprime un aviso y pasa. En la ejecución guardada hay varias rutas desplegadas sin ninguna fila en la matriz. Las de lectura son un problema; la que cambia datos, uno mayor, porque cualquier rol que llegue a ella depende de que el controlador recuerde comprobar algo.

Abre usuarios_de_prueba.yml: hay una cuenta por rol, y objeto_de_ejemplo siempre le da un recurso propio. Con ese diseño, la prueba nunca pide un objeto de otra cuenta del mismo rol. Lee incidentes.txt y busca el que es exactamente ese caso: un fallo entre dos personas con el mismo rol. Los otros dos también eran evitables, pero con otras pruebas (fallar cerrado cuando la política no responde, decidir con el rol vigente).

Con lo que encontraste, propón los cambios a la prueba.