El control de acceso roto (Broken Access Control) ocurre cuando la aplicación no verifica correctamente los permisos de quien hace la petición. Es la categoría #1 del OWASP Top 10 (2021). Su caso más común es IDOR (Insecure Direct Object Reference): acceder a un recurso ajeno cambiando un identificador.
IDOR en una línea
Un recurso se referencia con un identificador predecible y el servidor no comprueba la propiedad:
GET /api/factura?id=1043 → tu factura
GET /api/factura?id=1044 → ¡la factura de otro usuario!
Formas habituales
- IDOR horizontal: acceder a datos de otro usuario del mismo nivel (otra factura, otro mensaje).
- Escalada vertical: un usuario normal accede a funciones de administrador (
/admin) que no deberían estar disponibles. - Forzado de método o ruta: llamar directamente a un endpoint que la interfaz escondía.
Por qué pasa
La seguridad se aplica solo en la interfaz (ocultar un botón, no mostrar un enlace) en lugar de en el servidor. Ocultar no es proteger: cualquiera puede construir la petición a mano.
Las defensas
- Verificar la autorización en el servidor en cada petición, comprobando que el usuario autenticado sea dueño del recurso o tenga el rol necesario.
- Negar por defecto: todo está prohibido salvo lo explícitamente permitido.
- Usar identificadores no predecibles (UUID) ayuda, pero no sustituye la comprobación de permisos.
- Centralizar la lógica de acceso y probarla (dos cuentas, intentar cruzar datos).
Hasta acá el atacante pedía cosas él mismo. La próxima falla es más astuta: hace que el navegador de la víctima envíe una petición legítima sin que ella quiera. Es el CSRF, el próximo tema.