La frase suena como el título de un episodio donde los guardianes de las puertas se echan la siesta y cualquier polizón digital puede colarse hasta la sala de máquinas. Broken Access Control —o “cuando lo que no debería pasar… pasa”— es justo eso: el desorden silencioso que aparece cuando un sistema no comprueba bien quién puede hacer qué.
Si lo miras con ojos de ingeniería, el acceso es un filtro. Dejas pasar a quien debe pasar, bloqueas lo que debe bloquearse. Cuando ese filtro está roto, las cosas se vuelven raras: usuarios normales que pueden ver datos de admins, URLs ocultas accesibles por curiosidad, APIs que se creen cualquier identidad que les envías, o sesiones que no se invalidan cuando deberían.
En la jerga de seguridad, hablamos de:
IDOR (Insecure Direct Object Reference): accedes a /factura/1234 y cambias el número por 1235… y te muestra otra factura que no es tuya. Como si giraras la manivela de una taquilla y todas se abrieran igual.
Saltos de rol (Privilege Escalation): el usuario «profesor» se hace pasar por «director» porque la aplicación solo comprueba el rol en el cliente o confía en un parámetro no verificado.
Rutas ocultas accesibles por URL: páginas “solo para admins” que no comprueban si lo eres de verdad, solo si intentas llegar.
Faltas en el control de sesión: tokens que deberían expirar y no lo hacen, o sesiones que no se invalidan tras un logout.
OWASP en 2025 sigue catalogándola como una vulnerabilidad extremadamente común y de gran impacto. Tiene una cualidad casi poética: no requiere magia negra. A menudo no necesitas explotar buffers ni inventarte payloads complejos. Solo necesitas probar cosas que un usuario jamás debería poder hacer y ver si el sistema se molesta en decir que no.
La defensa siempre gira alrededor del mismo mantra sobrio:
La validación de permisos se hace en el servidor, nunca confiando en el cliente.
Se decide “¿puede este usuario acceder a este recurso?” en cada petición, no solo al inicio.
Se evitan identificadores predecibles.
Y se audita la lógica como si intentaras entrar en un museo fingiendo que solo buscas el baño.
En esencia, un sistema vulnerable permite que un usuario realice acciones o acceda a recursos que no le corresponden. Es como si un becario pudiera abrir la caja fuerte porque nadie se ha molestado en comprobar la llave.
1. Qué es realmente Broken Access Control
El sistema debería preguntar: “¿Quién eres?” (autenticación) “¿Qué puedes hacer?” (autorización)
Broken Access Control ocurre cuando se responde correctamente a la primera pregunta, pero se olvida la segunda. Es una pérdida de disciplina, un despiste en la mecánica de comprobar permisos en cada petición.
A efectos prácticos, se traduce así: Un usuario X puede alcanzar recursos destinados a usuarios Y, o incluso a administradores.
Los atacantes adoran esto porque no requiere técnicas oscuras. Solo curiosidad, persistencia y un poco de mala idea.
2. Tipos más frecuentes de fallos
Aquí está el zoológico de problemas que suelen aparecer:
IDOR (Insecure Direct Object Reference) Petición: /api/user/42 El atacante prueba: /api/user/43 La aplicación entrega datos ajenos. No hay magia, solo falta de control interno.
Escalada de privilegios Un usuario sin privilegios consigue actuar como otro más poderoso. A veces basta con modificar un parámetro como role=admin en una petición mal diseñada.
Acceso a rutas “ocultas” Hay páginas que se confían en el “nadie sabrá que existe esta URL”. Pero si la aplicación no verifica permisos, cualquiera que la visite entra como si nada.
Métodos HTTP insuficientemente protegidos Se bloquea GET, pero no DELETE. El atacante descubre que puede borrar recursos jugando con el verbo adecuado.
Controles en el cliente en vez del servidor JavaScript que “esconde” botones de administración, esperando que el usuario no los active manualmente. La ilusión del “seguridad por CSS”.
Sesiones mal invalidadas o tokens sin expiración El atacante reutiliza sesiones antiguas que todavía funcionan.
3. Por qué es tan común
Porque es un problema invisible. Los desarrolladores suelen centrarse en las funcionalidades visibles: botones, bases de datos, lógica de negocio. La autorización es más sutil. Si la aplicación funciona bien para los usuarios legítimos, se da por buena… y se olvida comprobar qué pasa si un usuario prueba lo que “no debería”.
Además, en sistemas con microservicios, APIs REST, contenedores y autenticación distribuida, mantener un control consistente en todos los puntos del sistema se convierte en un rompecabezas.
4. Impacto
El impacto es directo y contundente:
Filtración de datos privados
Modificación o borrado de información sensible
Toma de control parcial o total de cuentas
Acceso a funciones administrativas
Compromiso completo del sistema
No es una molestia menor: es una brecha.
5. Cómo detectar Broken Access Control
Las técnicas habituales recuerdan al trabajo detectivesco, probando caminos prohibidos:
Manipular parámetros: IDs, nombres, UUIDs.
Probar diferentes métodos HTTP.
Fuerza bruta sobre rutas en el servidor.
En APIs, repetir peticiones cambiando el “subject” del recurso.
Comprobar respuestas diferentes según roles.
Revisar la lógica interna buscando decisiones basadas en el cliente.
Aquí tus alumnos juegan casi a ser arqueólogos digitales, buscando grietas en la lógica.
6. Cómo prevenirlo
Los principios de defensa son sobrios pero muy efectivos:
Control de acceso en el servidor, siempre. El cliente nunca es una fuente de verdad. Puedes ocultar botones, pero la validación real debe hacerse en el backend.
Comprobación de permisos en cada petición. Cada vez que un usuario pide un recurso: “¿Puede este usuario acceder a este recurso concreto?”.
IDs no predecibles. Si no pueden adivinar el identificador, es más difícil explotar IDOR. Aunque no es una defensa completa, ayuda.
Tokens con expiración y revocación real. Una sesión debe morir cuando se cierra sesión.
Segregación de funciones. Accesos administrativos separados y auditados. No mezclar roles como si fuesen cromos repetidos.
Registros y auditorías. Si algo falla, debe quedar rastro. Los sistemas sin logs son como cajas negras sin grabadora.
Pruebas de control de acceso automatizadas. Integrarlas en el pipeline evita que años después aparezca el clásico “¿cómo que cualquier usuario puede borrar pedidos?”.
7. Ejemplo narrado
Imagina que gestionas una tienda online. Un usuario autenticado visita:
GET /pedidos/1287
La aplicación entrega su pedido correctamente. Pero el atacante cambia el número:
GET /pedidos/1288
Si aparece otro pedido, hay un IDOR. La aplicación ha dado por hecho que si conoces el número, eres su dueño.
Ahora imagina otra escena. En el panel interno, un usuario intenta acceder a:
/admin/usuarios/listado
La página carga sin comprobar su rol. Ese es el acceso directo a funciones críticas: falta de verificación de roles.
En el tercer acto, un token de sesión sigue funcionando horas después del logout. Resultado: sesión no invalidada, un regalo para cualquiera que haya interceptado ese token.
9. Relación con APIs modernas
En sistemas basados en tokens (JWT, OAuth2), microservicios y Kubernetes, el control de acceso ya no es un único portero, sino un equipo entero. Cada servicio debe validar el token, verificar permisos y, sobre todo, no confiar en nada que venga del exterior.
Los fallos en estos entornos suelen ser:
Servicios internos que no verifican el scope del token.
Roles definidos en el cliente, no en el backend.
Comunicaciones entre microservicios sin autenticación mutua.
Las APIs son un campo fértil para este tipo de errores.
