Control de Acceso Roto
Autenticación frente a Autorización
Es crucial distinguir dos conceptos que suelen confundirse. La autenticación responde a "¿quién eres?"; la autorización responde a "¿qué tienes permitido hacer?". El control de acceso es la implementación de la autorización: las reglas que determinan qué recursos y acciones puede usar cada usuario. Cuando estas reglas están ausentes, son incompletas o se aplican incorrectamente, hablamos de control de acceso roto.
El OWASP Top 10 sitúa el Broken Access Control en la primera posición (A01:2021), porque es la categoría de vulnerabilidad más extendida y frecuentemente explotada. La razón es que el control de acceso depende de la lógica de negocio específica de cada aplicación: no hay un parche genérico, y es muy fácil olvidarse de proteger algún endpoint o de verificar la propiedad de un recurso.
IDOR: Referencias Directas Inseguras a Objetos
La IDOR (Insecure Direct Object Reference, CWE-639) es una de las formas más comunes de control de acceso roto. Ocurre cuando una aplicación expone una referencia directa a un objeto interno (como un identificador numérico en la URL) y usa ese valor para acceder a un recurso sin verificar que el usuario actual tiene derecho a verlo.
Por ejemplo, si al ver tu factura la URL contiene factura?id=1024 y la aplicación simplemente devuelve la factura con ese identificador sin comprobar que te pertenece, cambiar el número a 1025 podría mostrarte la factura de otra persona. El mecanismo conceptual es simple: el servidor confía en un parámetro controlado por el usuario para decidir qué datos entregar, sin una comprobación de autorización del lado del servidor. Las IDOR pueden afectar a la lectura, modificación o borrado de datos ajenos, y son fáciles de descubrir con un proxy como Burp Suite observando los identificadores en las requests.
Escalada de Privilegios
La escalada de privilegios horizontal ocurre cuando un usuario accede a recursos de otro usuario del mismo nivel: por ejemplo, leer los mensajes privados de otra cuenta de cliente. La IDOR es a menudo el vehículo de este tipo de escalada. El atacante no obtiene más poder, pero sí acceso a datos que no le corresponden.
La escalada de privilegios vertical es más grave: un usuario con pocos permisos logra realizar acciones reservadas a roles superiores, como un usuario normal que accede al panel de administración. Esto suele ocurrir cuando la aplicación oculta las funciones administrativas en la interfaz pero no las protege en el servidor, asumiendo erróneamente que "si no se ve el botón, nadie puede llamar a la función". Un atacante que conozca o adivine la URL del endpoint administrativo puede invocarlo directamente. Recuerda el principio: la seguridad no puede depender de ocultar funcionalidad en el cliente.
Otros Patrones de Control de Acceso Roto
Más allá de la IDOR y la escalada, existen otros patrones frecuentes. El forced browsing consiste en acceder directamente a URLs o archivos no enlazados desde la interfaz, descubriendo paneles o recursos que se creían ocultos. La manipulación de metadatos ocurre cuando un atacante modifica un token, una cookie o un campo (por ejemplo un campo role=user) para elevar sus permisos.
También entran aquí los problemas de CORS mal configurado que permiten que sitios no autorizados consuman APIs protegidas, y los fallos donde una API confía en parámetros del cliente para decidir el rol o el tenant. El denominador común de todos estos casos es el mismo: la decisión de autorización se toma en un lugar manipulable o no se toma en absoluto. Cada acción sensible debe preguntarse explícitamente "¿este usuario, en este momento, tiene derecho a hacer esto sobre este recurso concreto?".
Cómo Prevenir el Control de Acceso Roto
La regla de oro es denegar por defecto: ninguna acción debe permitirse a menos que exista una verificación explícita que la autorice. Centraliza la lógica de control de acceso en un único componente reutilizable en lugar de dispersar comprobaciones ad-hoc por todo el código; así es más difícil olvidar una. Verifica siempre en el servidor que el usuario autenticado es el propietario del recurso o tiene el rol necesario, en cada request, sin confiar en lo que envíe el cliente.
Adopta un modelo claro de control de acceso, como RBAC (basado en roles) o ABAC (basado en atributos), y aplica el principio de mínimo privilegio. Evita exponer identificadores predecibles cuando sea posible, o al menos no los uses como único criterio de acceso. Prueba el control de acceso de forma sistemática: con varias cuentas de distinto privilegio, intenta acceder a recursos cruzados usando Burp Suite o OWASP ZAP. El control de acceso es difícil de automatizar por completo, por lo que la revisión manual y las pruebas dirigidas son insustituibles para encontrar IDOR y fallos de escalada.