En muchas ocasiones no hablamos de ataques sofisticados ni de complejas cadenas de explotación. Basta con modificar un identificador dentro de una petición para acceder a recursos que pertenecen a otros usuarios.
Cuando estar autenticado no es suficiente
Uno de los errores más comunes durante el desarrollo es asumir que un usuario autenticado es un usuario autorizado.
La autenticación responde a la pregunta:
¿Quién eres?
Mientras que la autorización responde:
¿Qué puedes hacer?
Un usuario puede estar perfectamente autenticado mediante un JWT válido y, aun así, no tener permisos para consultar, modificar o eliminar determinados recursos.
Sin embargo, en muchas aplicaciones el backend confía en el identificador recibido en la petición sin comprobar si realmente pertenece al usuario autenticado.
El patrón que más se repite
Durante auditorías es habitual encontrar APIs con endpoints similares a:
GET /api/users/123
La aplicación verifica que el JWT es válido y devuelve la información solicitada.
El problema aparece cuando un atacante modifica el identificador:
GET /api/users/124
Si el backend únicamente valida la autenticación y no comprueba que el usuario tiene permisos sobre el recurso solicitado, estará devolviendo información de otro usuario.
Este mismo patrón puede afectar a pedidos, documentos, expedientes, facturas, cuentas bancarias o cualquier objeto identificado mediante un ID.
Este patrón es, de hecho, exactamente lo que OWASP API Security Top 10 categoriza como API1:2023 Broken Object Level Authorization (BOLA): el primer riesgo de la lista, considerado el más crítico en seguridad de APIs modernas.
El verdadero riesgo: la automatización
Un error de autorización aislado puede parecer poco relevante.
Sin embargo, una vez identificado el patrón, un atacante puede automatizar el proceso mediante herramientas de fuzzing o scripts que prueben cientos o miles de identificadores diferentes.
El impacto deja de afectar a un único usuario para convertirse en una exposición masiva de información.
Además, la explotación no se limita a operaciones de lectura. Es frecuente encontrar operaciones de modificación, eliminación o ejecución de acciones críticas sobre recursos de terceros.
Swagger y la enumeración de funcionalidades
Muchas APIs publican documentación mediante Swagger/OpenAPI.
Aunque esta documentación resulta muy útil para desarrolladores, también proporciona a un atacante un mapa detallado de los endpoints disponibles, los métodos HTTP soportados y los parámetros necesarios para interactuar con la aplicación.
Esto facilita enormemente la enumeración de funcionalidades y la identificación de recursos susceptibles de ser manipulados. En entornos de producción es buena práctica restringir el acceso a las especificaciones OpenAPI a usuarios autenticados o, directamente, no exponerlas públicamente.
No siempre hablamos de atacantes externos
Existe la percepción de que este tipo de vulnerabilidades únicamente pueden ser explotadas por ciberdelincuentes externos.
La realidad es distinta.
En la mayoría de los casos basta con disponer de una cuenta válida en la aplicación. Un empleado, un proveedor externo o cualquier insider con acceso legítimo podría abusar de estos fallos para consultar o modificar información que no debería estar a su alcance.
Por ello, los IDOR representan un riesgo tanto para la seguridad externa como para la seguridad interna de una organización.
Esta dimensión interna tiene además implicaciones regulatorias relevantes. Bajo el RGPD, una vulnerabilidad IDOR que permita el acceso no autorizado a datos personales puede constituir por sí misma un incumplimiento de las obligaciones de seguridad de los artículos 5.1.f y 32, con independencia de que llegue a producirse un ataque demostrable.
¿Por qué siguen apareciendo?
Los patrones observados en auditorías suelen repetirse:
- Confianza excesiva en identificadores recibidos en la petición.
- Validaciones incompletas de autorización.
- Controles inconsistentes entre distintos endpoints.
- Lógica de negocio insegura.
- Falta de comprobación de ownership sobre los recursos.
En la mayoría de los casos no se trata de vulnerabilidades técnicas complejas, sino de errores de diseño en la lógica de autorización.
En arquitecturas modernas basadas en microservicios estos problemas se agravan: cada servicio puede implementar su propia lógica de autorización, sin una capa transversal que la unifique. Lo que en una API monolítica era un único punto de control se convierte en docenas de comprobaciones repartidas, cualquiera de las cuales puede olvidarse o implementarse incorrectamente.
Cómo prevenir un IDOR
La principal medida de mitigación es sencilla:
Nunca confiar en los identificadores recibidos desde el cliente.
Cada petición debe comprobar que el usuario autenticado tiene permisos sobre el recurso solicitado antes de realizar cualquier operación.
En la práctica, a esta comprobación se la conoce como validación de ownership o autorización a nivel de objeto: verificar que el recurso solicitado pertenece —o es accesible— al usuario que hace la petición, en cada operación y para cada endpoint.
Además, es recomendable:
- Centralizar la lógica de autorización.
- Validar ownership en todas las operaciones (lectura, modificación y eliminación).
- Realizar pruebas específicas de autorización durante el desarrollo y las auditorías de seguridad.
- Revisar periódicamente las APIs expuestas y sus controles de acceso.
- Usar identificadores no enumerables, como UUID v4, en lugar de IDs secuenciales. Esta medida no resuelve el IDOR por sí sola —la comprobación de autorización sigue siendo imprescindible—, pero dificulta enormemente la enumeración automatizada y eleva el coste del ataque.
Conclusión
Los IDOR siguen siendo una de las vulnerabilidades más frecuentes porque explotan un aspecto fundamental de cualquier aplicación: la autorización.
No es necesario romper la autenticación, vulnerar un JWT o explotar una compleja vulnerabilidad de ejecución remota. En muchos casos basta con modificar un identificador y comprobar si el backend valida correctamente los permisos sobre el recurso solicitado.
La autenticación responde quién eres.
La autorización responde qué puedes hacer.
La seguridad depende de validar ambas correctamente.
Para profundizar
- OWASP API Security Top 10 (2023) — categoría API1:2023 Broken Object Level Authorization (BOLA).
- CWE-639: Authorization Bypass Through User-Controlled Key — MITRE.
- PortSwigger Web Security Academy — IDOR vulnerabilities — laboratorios prácticos y ejemplos.
Speak Your Mind