API5:2023 – Broken Function Level Authorization

API desde 0

marzo 23, 2026

3,2,1 … Empezamos!

Nueva entrada en el blog continuando la entrada anterior, dónde se explicaba la vulnerabilidad API4:2023 Unrestricted Resource Consumption

Se recomienda leer estos artículos antes de continuar con la lectura:

Tanto esta, como las siguientes publicaciones van a tratar en detalle cada vulnerabilidad que compone el TOP 10 – API 2023.

¡Espero que os resulte útil!

API5:2023 – Broken Function Level Authorization

Descripción

La vulnerabilidad API5:2023 – Broken Function Level Authorization (BFLA) continúa presente en la lista OWASP API Top 10, repitiendo nombre respecto a su versión de 2019 (API5:2019). Esto refleja su persistencia como una amenaza crítica en arquitecturas modernas basadas en APIs, donde la complejidad de roles, endpoints y lógicas de negocio se ha incrementado exponencialmente.

En términos simples, esta vulnerabilidad se produce cuando una API no valida de manera adecuada que un usuario tenga los privilegios necesarios para ejecutar una función concreta. Es decir, aunque el endpoint exista y sea accesible, no debería permitir la ejecución de determinadas operaciones a usuarios no autorizados.

Este fallo puede adoptar dos formas:

Escalada de privilegios vertical: cuando un usuario con permisos bajos (por ejemplo, un cliente) accede a funciones reservadas para roles con mayor autoridad (como administradores).
Escalada lateral: cuando un usuario accede a funciones disponibles para su rol, pero asociadas a otros usuarios o entidades, accediendo así a datos o funcionalidades que no le corresponden.

Las APIs suelen tener múltiples tipos de usuarios: clientes finales, comerciantes, socios, técnicos, vendedores, empleados internos y administradores, entre otros. Cada tipo debería tener acceso solo a las funciones necesarias según su rol. Sin embargo, cuando la API expone endpoints sin verificar correctamente estos permisos, el atacante puede aprovechar esta falta de control para invocar operaciones críticas.

Como la mejor forma de entender las cosas es con ejemplos, vamos a ver esta vulnerabilidad con una situación que se puede dar:

En este caso, el contexto se centra en un borrado de usuarios de la API. Ana quiere borrar el usuario con ID 100, realiza la petición y dicho usuario se borra correctamente. Ana puede realizar esta petición debido a que su usuario tiene permiso para realizar dicha acción.

Si la vulnerabilidad está presente, en el caso de que un atacante intente hacer la misma petición que Ana, al no estar correctamente configurada la API, puede realizar la misma petición, llegando a borrar también cualquier usuario.

API5:2023 – Broken Function Level Authorization

Una correcta implementación de acceso a ciertos endpoints sería el siguiente caso:

Ana podría eliminar sin problema el usuario porque su usuario tiene permisos en la API para realizar esa acción.

En cambio, cualquier usuario que no tenga permiso sobre ese endpoint, no podría realizar esa acción, debido a que solamente tienen permisos ciertos usuarios y el resto de usuario no podrían realizar dicha acción, siendo esta denegada.

Impacto

El impacto de esta vulnerabilidad puede tener un gran impacto tanto para la seguridad como para la reputación de una organización. Al permitir a un usuario acceder a funciones que no le corresponden, se rompe uno de los principios fundamentales de seguridad: el control de acceso basado en roles.

Los riesgos más destacados incluyen:

Acceso no autorizado a funcionalidades críticas: como la gestión de cuentas, configuración del sistema, control de flujos financieros, etc.
Divulgación de información sensible: si se accede a endpoints relacionados con datos personales, financieros, sanitarios o corporativos protegidos por normativas como RGPD.
Modificación o eliminación de datos: un atacante podría manipular o borrar recursos de otros usuarios, alterando el comportamiento del sistema o generando pérdidas de integridad.
Account Takeover (ATO): cuando el endpoint permite modificar credenciales o gestionar sesiones, es posible tomar el control de otras cuentas.
Interrupción del servicio: al ejecutar operaciones de configuración, eliminación masiva o reconfiguración, puede provocarse una caída del sistema o tener una bajada sustancial en el rendimiento.

Además del daño técnico, una brecha causada por BFLA puede derivar en pérdida de confianza de los clientes, sanciones regulatorias y costes legales importantes.

Recomendaciones

Mitigar esta vulnerabilidad requiere una combinación de buenas prácticas de desarrollo seguro, validaciones robustas y revisión periódica de la lógica de autorización en todos los endpoints expuestos por la API.

A continuación, se detallan las principales recomendaciones:

Modelo de autorización centralizado y estructurado
- Implementar un sistema de control de acceso robusto y reutilizable (por ejemplo, basándose en OAuth 2.0, RBAC o ABAC).
- La lógica de autorización debe residir en una capa común del backend y no depender únicamente del cliente o del frontend.
- Evitar escribir reglas de autorización directamente en los controladores de cada endpoint, ya que esto aumenta la posibilidad de errores y omisiones.
Principio de denegación por defecto
- Toda funcionalidad debe estar bloqueada por defecto.
- El acceso solo debe concederse de forma explícita a roles autorizados para cada operación específica.
Revisión exhaustiva de endpoints y lógica de negocio
- Auditar todos los endpoints de la API para verificar que las restricciones de acceso están alineadas con los privilegios necesarios.
- Validar no solo que los usuarios estén autenticados, sino que también estén autorizados para ejecutar la operación solicitada en función de su rol y contexto.
- Revisar también posibles inconsistencias en las rutas o patrones de URL que permitan el acceso indirecto a funciones privilegiadas.
Restricción de métodos HTTP
- Asegurar que cada endpoint solo acepte los métodos HTTP necesarios: si una ruta debe ser solo de lectura (GET), impedir métodos como POST, PUT, DELETE, etc.
- Muchos ataques BFLA se basan en abusar de métodos inesperados para ejecutar acciones no autorizadas.
Validación contextual y control de identidad
- Validar que el usuario autenticado solo pueda acceder a los recursos que le pertenecen.
- Implementar lógicas que contemplen jerarquías, contextos organizativos o dependencias funcionales en la autorización.
Pruebas de seguridad y automatización
- Incluir pruebas de BFLA en las baterías de tests automatizados y en auditorías de seguridad.
- Simular escenarios de escalada de privilegios y uso lateral con herramientas como Postman, Burp Suite, Insomnia, o scripts personalizados.
- Monitorizar intentos sospechosos de acceso a funciones elevadas desde cuentas no privilegiadas.