Bob inicia sesión en la API del laboratorio con su propia cuenta válida, solicita GET /invoices/inv_100 y recibe la factura de Alice. El atacante no robó un token, ni eludió el inicio de sesión, ni adivinó una contraseña. Bob modificó un identificador de objeto en una ruta que el servidor aceptó sin verificar si inv_100 pertenece a Bob. Por tanto, la pregunta que debe plantearse el defensor es más específica y útil que simplemente si el inicio de sesión funciona: ante cada solicitud, ¿verifica la API que el sujeto autenticado tiene permiso para realizar esa operación sobre ese objeto?
El componente con el que trabajamos es una pequeña API REST que incluye POST /login, GET /invoices/{invoiceId}, PUT /invoices/{invoiceId} y GET /admin/audit. Alice es propietaria de inv_100, Bob lo es de inv_200, y un administrador puede leer los registros de auditoría. Un modelo de amenazas identifica qué controla ya el atacante, qué límite cruza la solicitud, qué pretende el atacante y qué decisión del servidor debe detener dicha solicitud. En este caso, Bob controla su solicitud autenticada y el invoiceId; quiere obtener la factura de Alice, por lo que el mecanismo de autorización debe denegar el acceso antes de que los datos salgan del almacén de información.
La autenticación confirma que la solicitud proviene de Bob. Sin embargo, la autorización debe determinar si Bob tiene permiso para leer inv_100. Tratar ambas decisiones como una única comprobación provoca el fallo de seguridad, ya que una identidad válida no implica necesariamente derechos de propiedad ni privilegios administrativos. Nuestro objetivo a lo largo del curso es reforzar la seguridad de esta misma API y demostrar que cada límite de seguridad resiste las pruebas. El siguiente esquema muestra los límites que cruza Bob.
Este diagrama muestra por qué una solicitud puede superar la autenticación pero fallar en la autorización o en el acceso a los datos. El identificador de objeto se vuelve peligroso solo cuando la API lo utiliza para recuperar un registro sin vincular dicho registro a la entidad autenticada (principal).
La ausencia de una verificación de propiedad corresponde a la vulnerabilidad API1:2023 Broken Object Level Authorization (Autorización a nivel de objeto rota), o BOLA, dentro de la lista OWASP API Security Top 10 de 2023. Cualquier endpoint que reciba un ID de objeto controlado por el cliente requiere una decisión de autorización específica para ese objeto. GET /invoices/inv_100 y PUT /invoices/inv_100 son operaciones distintas; por tanto, cada una requiere su propia decisión, incluso cuando ambas hacen referencia a la misma factura.
Otros riesgos iniciales se agrupan en torno a la misma ruta de solicitud. API2:2023 Broken Authentication (Autenticación rota) se refiere a si la API identifica correctamente a Bob. API3:2023 Broken Object Property Level Authorization (Autorización a nivel de propiedad de objeto rota) trata sobre si la respuesta de una factura autorizada expone o acepta campos a los que Bob no debería tener acceso, como un límite de aprobación interno (approvalLimit). API4:2023 Unrestricted Resource Consumption (Consumo de recursos sin restricciones) se refiere a que Bob envíe solicitudes costosas con la frecuencia suficiente para agotar la capacidad o desencadenar procesos posteriores que impliquen costes. API5:2023 Broken Function Level Authorization (Autorización a nivel de función rota) se refiere a que Bob acceda a GET /admin/audit a pesar de no contar con permisos administrativos.
Cada categoría modifica una parte distinta de la solicitud, pero todas evalúan si el servidor impone límites de seguridad en lugar de confiar ciegamente en la entrada del cliente, en un simple token o en el nombre del endpoint. La tabla analiza el cambio realizado por el atacante, el resultado que se busca proteger y las evidencias que necesitan los defensores.