El control de acceso roto y su matriz de roles

En la edición 2025 del Top 10 de OWASP, el control de acceso roto ocupa el primer lugar (A01:2025 Broken Access Control), y la guía de pruebas de OWASP (WSTG) lo cubre en su sección de autorización, con pruebas como WSTG-ATHZ-02, «Testing for Bypassing Authorization Schema». La idea común: la aplicación debe hacer cumplir, en el servidor y en cada petición, qué puede hacer cada persona según su rol y su propiedad sobre los datos.

Para probarlo hace falta algo previo a cualquier petición: saber qué debería pasar. Sin ese «esperado», un 200 en una página de administración no es un hallazgo ni una normalidad: es un número sin referencia. Por eso el primer paso es pedir al cliente su matriz de roles (qué función puede usar cada rol) y, si no existe, reconstruirla con él antes de probar. La prueba entonces es mecánica: una cuenta por rol, cada función, y se anota esperado y obtenido.

Un 403 significa «sé quién eres y no puedes». Un 401 significa «no sé quién eres». Un 404 o una redirección al inicio de sesión (302) también pueden negar el acceso, aunque el servidor lo diga con otras palabras. Lo que importa para el hallazgo no es que el código coincida con el esperado, sino si la función se ejecutó o se entregó contenido a quien no debía.

Cuidado con los dos errores opuestos. Reportar todo código distinto del esperado ensucia el informe y le quita credibilidad al resto; descartar un 200 porque «la página parecía vacía» deja pasar un fallo real, porque el contenido que importa puede venir en otra parte de la respuesta. Se anota la diferencia, se mira el contenido y se decide con eso.

En la prueba de Despensa Andina, la fila 8 esperaba 403 de la ruta de pedidos de sucursal con la cuenta de cliente, y el servidor devolvió 404.

Abre el laboratorio y consulta la tabla de pruebas. Las filas cuyo obtenido es 200 y cuyo esperado es 403 son los accesos concedidos fuera del diseño. Mira a qué rol pertenece cada una: una función que responde a dos roles distintos que debían quedar fuera suele indicar que no hay control en esa ruta para nadie, y no un descuido con un rol concreto.

Con ese cruce, el hallazgo se redacta sobre la función («exportar la lista de clientes responde a cualquier sesión»), no sobre las cuentas con las que se descubrió.

Un informe necesita cifras que otra persona pueda comprobar. Contar cuántas pruebas dieron acceso donde el diseño decía que no es un dato de partida del hallazgo: dimensiona el problema y permite comprobar, tras la corrección, que la cuenta vuelve a cero.

Cuenta solo las pruebas en que el servidor concedió acceso (200) y el diseño lo negaba (403), sin incluir las diferencias de código que niegan igual.