Denegar por defecto y comprobar en cada petición

Denegar por defecto significa que el acceso se concede solo cuando una regla lo permite de forma expresa. Todo lo demás (una ruta nueva sin regla, una acción que nadie previó, un error al consultar la política) termina en denegar. Las recomendaciones de OWASP sobre autorización lo ponen entre sus primeros principios, junto con el mínimo privilegio, y el módulo 14 lo trató como fallar cerrado.

La razón es asimétrica: si una regla falta y el sistema deniega, alguien se queja y se escribe la regla; si falta y el sistema permite, nadie se queja y el hueco queda abierto hasta que lo encuentre quien no debía. Abre middleware_autorizacion.py y lee las dos ramas que devuelven PERMITIR sin preguntar a la política.

El comentario del middleware supone que una ruta sin regla es una ruta nueva que todavía no se usa. Pero una ruta desplegada responde desde el primer día. Compara rutas-desplegadas.txt con reglas_por_ruta.yml: las que aparecen en el primero y no en el segundo pasan sin preguntar a nadie.

De las que faltan, una solo lee; la otra cambia un dato que en una constructora vale dinero.

Un punto de decisión centralizado es también un punto único de fallo, y lo que haga la aplicación cuando no responde es una decisión de diseño, no un detalle. Abrir la puerta «para no frenar la obra» convierte cada caída en una ventana en la que no rige ninguna regla. Fallar cerrado tiene un costo visible (la gente no puede trabajar unos minutos) y por eso se acompaña de alta disponibilidad del servicio de política, no de una excepción que permite.

Lee registro-politica.log y mide lo que se resolvió sin política.

Comprobar en cada petición significa decidir con los permisos de ahora, no con los del momento en que la persona inició sesión. Un token o una sesión que guarda los roles del ingreso deja vivo un permiso retirado hasta que caduque. Por eso las decisiones sensibles consultan el estado actual, y los tokens de vida larga no se usan como fuente de permisos.

Abre api_movil.py y cruza eventos-roles.txt con aprobaciones-caja-menor.log. Fíjate en el canal de cada aprobación de la persona a la que le retiraron el rol.

Los tres hallazgos tienen la misma raíz: hay caminos en los que la aplicación concede acceso sin una regla que lo permita en ese momento.