OWASP: A01 2025 - Broken Access Control
¿Qué es Broken Access Control?
Son fallos donde un usuario puede acceder o actuar sobre recursos/funciones que no le corresponden según su rol o identidad: ver datos de otro usuario, ejecutar funciones de admin siendo usuario normal, o hacer que el servidor realice peticiones a recursos internos en su nombre.
En este artículo analizamos las siguientes áreas:
IDOR (Insecure Direct Object Reference)
Path / Directory Traversal
Escalada de privilegios vertical
Escalada de privilegios horizontal
Manipulación de atributos y Mass Assignment
SSRF (Server-Side Request Forgery)
CSRF (Cross-Site Request Forgery)
CORS (Cross-Origin Resource Sharing)
IDOR (Insecure Direct Object Reference)
Busca cualquier endpoint que permita acceder a un recurso mediante un identificador controlado por el cliente, por ejemplo un ID numérico, UUID, username o cualquier otra referencia incluida en la URL, los parámetros o el cuerpo de la petición.
GET /api/user/7865/invoice
GET /api/users/sam/profile
GET /api/orders?order_id=7865
El objetivo es comprobar si el servidor valida que el usuario autenticado tiene autorización para acceder al recurso solicitado, y no únicamente que dispone de una sesión válida.
Por ejemplo, si un usuario puede consultar su propia factura mediante:
GET /api/user/7865/invoice
prueba a sustituir 7865 por el identificador de otro recurso:
GET /api/user/7866/invoice
Si el servidor devuelve información perteneciente a otro usuario sin comprobar los permisos sobre ese objeto, existe un problema de control de acceso que puede dar lugar a un IDOR.
Una implementación correcta debería impedir el acceso al recurso cuando el usuario no está autorizado. Dependiendo de cómo esté diseñada la aplicación, la respuesta puede ser, por ejemplo, 403 Forbidden o 404 Not Found.
Automatizar la búsqueda de IDOR
Cuando los identificadores son predecibles o enumerables, puedes automatizar la prueba enviando la misma petición con distintos valores, por ejemplo sustituir {ID} por: 7860, 7861 o 7862.
GET /api/user/{ID}/invoice
La técnica no depende de una herramienta concreta: puede hacerse con un proxy de interceptación, un fuzzer, un script o cualquier herramienta que permita modificar y repetir peticiones HTTP.
Al comparar las respuestas, presta atención a cambios en:
- Código de estado HTTP
- Tamaño y estructura de la respuesta
- Número de palabras o líneas
- Otro valor que indique que se ha accedido a un objeto diferente.
El objetivo no es simplemente encontrar respuestas distintas, sino determinar si alguna de ellas expone un recurso al que el usuario que realiza la petición no debería tener acceso.
Red Team OPSEC
Evita enumerar identificadores de forma agresiva sin necesidad. Un volumen elevado de peticiones puede activar controles defensivos, bloquear cuentas, generar alertas o afectar al servicio.
Path / Directory Traversal
Un Path Traversal o Directory Traversal ocurre cuando una aplicación utiliza una ruta proporcionada por el usuario para acceder a archivos del sistema sin restringir correctamente qué ubicaciones pueden consultarse.
El problema aparece cuando el usuario puede modificar esa ruta y salir del directorio previsto por la aplicación, por ejemplo:
GET /download?file=report.pdf
Si el backend construye internamente una ruta como:
/var/www/files/report.pdf
Debes comprobar si el parámetro permite influir en otras partes del sistema de archivos.
Detección
Busca funcionalidades que trabajen con nombres de archivo, rutas o recursos almacenados localmente como descarga de archivos o visualización de documentos.
Validación
Una prueba típica consiste en introducir secuencias que representen directorios superiores ../. Si la aplicación lo interpreta sin normalizar o validar correctamente la ruta, puede terminar accediendo a archivos situados fuera del directorio previsto.
La validación debe realizarse sobre la ruta final normalizada, no únicamente sobre el texto original enviado por el usuario.
Una prueba habitual en Linux consiste en intentar acceder a /etc/passwd, ya que permite confirmar un Path Traversal con un archivo conocido y generalmente no sensible en términos de credenciales.
GET /download?file=../../../../etc/passwd
La prueba debe centrarse en determinar si puedes controlar la ubicación real del archivo que abre el servidor.
Red Team OPSEC
Evita utilizar Path Traversal para recopilar archivos sensibles de forma indiscriminada y evita descargar credenciales, claves o grandes volúmenes de información si no es necesario.
Escalada de privilegios vertical
La escalada de privilegios vertical ocurre cuando un usuario con pocos privilegios, o incluso un usuario no autenticado, consigue acceder a funcionalidades, recursos o datos reservados para roles superiores.
El objetivo es comprobar si el backend aplica correctamente los controles de autorización en cada operación privilegiada, en lugar de confiar únicamente en que ciertas rutas o funciones no sean visibles desde la interfaz.
Mapeo de la Superficie de Ataque
El primer paso consiste en descubrir endpoints ocultos, rutas administrativas, llamadas a la API y parámetros que no estén debidamente protegidos.
Algunas fuentes habituales son:
- Crawling o navegación de la aplicación.
- Fuzzing de directorios y endpoints: /admin, /dashboard, /api/admin/*
- Inspección de archivos estáticos, JavaScript y datos enviados al servidor.
- Rutas y parámetros descubiertos en respuestas del servidor o documentación.
Pruebas de control de acceso
Una vez mapeados los objetivos potenciales, se debe evaluar el control de acceso bajo dos escenarios principales:
A. Acceso sin Autenticación
Envía la petición sin cookies, tokens ni otras credenciales:
GET /api/admin/users Host target.comEl objetivo es comprobar si una funcionalidad reservada puede utilizarse sin haber iniciado sesión.
B. Acceso con una cuenta de bajo privilegio
Si la aplicación requiere autenticación, repite la petición utilizando las credenciales de un usuario estándar:
GET /api/admin/users Host: target.com Cookie: session=eyJhbGciOi...La técnica consiste en mantener la misma identidad de bajo privilegio y solicitar directamente una operación destinada a un rol superior.
Validación
Una respuesta HTTP 200 OK por sí sola no confirma automáticamente una vulnerabilidad. Hay que verificar el contenido de la respuesta:
-
Falsos positivos comunes: El servidor puede renderizar una página de inicio de sesión o un mensaje de error personalizado en el cuerpo (soft 404).
-
Validación de la respuesta: Confirma que el contenido exponga información real de administración o permita ejecutar acciones privilegiadas.
-
Fuga de información por diseño defectuoso: Si el backend responde con un código 403 Forbidden pero el enlace o panel era visible en el frontend para usuarios sin privilegios, documéntalo como un fallo de diseño y exposición de información de la interfaz de usuario.
La vulnerabilidad se confirma cuando el usuario puede consultar información o ejecutar una operación para la que su rol no dispone de autorización.
Red Team OPSEC
Evita ejecutar acciones administrativas destructivas o irreversibles únicamente para confirmar que el control de acceso es vulnerable.
El objetivo es demostrar que el usuario puede superar el límite de privilegios, no explotar todas las acciones administrativas disponibles.
Escalada de privilegios horizontal
La escalada horizontal ocurre cuando la manipulación permite actuar sobre recursos pertenecientes a otro usuario con un nivel de privilegios equivalente.
Por ejemplo, una API podría asociar explícitamente el recurso mediante un parámetro recibido del cliente:
PUT /api/profile HTTP/1.1
Cookie: session=eyJhbGciOi...
Content-Type: application/json
{
"user_id": 3,
"name": "sam",
"password": "ba749123354ff600688394f4311376da"
}
Si el servidor permite sustituir user_id por el identificador de otro usuario y modifica su perfil sin comprobar la propiedad del recurso, existe un fallo de autorización horizontal.
La vulnerabilidad no está en que el identificador sea modificable, sino en que el backend confía en ese valor sin verificar que el usuario autenticado tenga permiso sobre el objeto indicado.
Manipulación de atributos y Mass Assignment
Un caso particular de fallo de autorización aparece cuando el cliente puede añadir o modificar atributos que deberían estar fuera de su control, como role, is_admin o verified, y el backend los procesa junto con el resto del objeto sin filtrarlos.
{
"name": "sam",
"email": "sam@example.com",
"role": "admin"
}
Este comportamiento suele producirse cuando el servidor deserializa directamente el cuerpo de la petición sobre un modelo interno (mass assignment / over-posting) en lugar de aplicar una lista explícita de campos permitidos.
El tratamiento técnico completo de mass assignment se desarrolla en A08 2025 - Software or Data Integrity Failures. Aquí interesa especialmente cuando el atributo manipulado concede un privilegio o autorización que el usuario no debería tener.
Validación
No consideres vulnerable un endpoint únicamente porque acepte campos adicionales.
Por ejemplo, una respuesta puede devolver el campo enviado simplemente porque refleja el JSON recibido, aunque el valor no haya sido almacenado.
Comprueba si:
- El atributo aparece realmente modificado en una consulta posterior.
- El cambio persiste después de volver a cargar o iniciar sesión.
- La modificación proporciona acceso a nuevas funcionalidades o recursos.
- El servidor ignora el campo, lo normaliza o lo sobrescribe internamente.
La vulnerabilidad se confirma cuando el usuario puede modificar un atributo que debería estar fuera de su control y ese cambio tiene un efecto real sobre el recurso o sus privilegios.
Red Team OPSEC
Evita utilizar campos sensibles sobre cuentas reales cuando el cambio pueda afectar permisos, estado de la cuenta o acceso de otros usuarios y recuerda registrar el estado original para poder restaurarlo.
Para demostrar el impacto normalmente es suficiente confirmar que el servidor permite modificar un atributo protegido.
SSRF (Server-Side Request Forgery)
Una vulnerabilidad SSRF aparece cuando una aplicación permite que el usuario influya en una petición realizada por el propio servidor hacia otro recurso.
En lugar de que sea el navegador del usuario quien realiza la conexión, es el backend quien obtiene el recurso solicitado.
Por ejemplo:
POST /api/import?url=https://objetivo-legitimo.com/imagen.jpg
El riesgo aparece cuando el usuario puede modificar el destino de esa petición y conseguir que el servidor contacte con recursos que normalmente no son accesibles desde Internet.
La pregunta clave durante las pruebas es: ¿Hasta qué punto puedo controlar el destino de una petición realizada por el servidor?.
Probar Server-Side fetch
Busca cualquier funcionalidad donde la aplicación reciba una URL, hostname, dominio o referencia remota y posteriormente obtiene ese recurso desde el backend, por ejemplo:
POST /api/import HTTP/1.1
Content-Type: application/json
{
"url": "https://example.com/image.jpg"
}
No te limites a buscar parámetros llamados explícitamente url. Una dirección remota puede aparecer dentro de estructuras más complejas.
Confirmar que la petición se realiza desde el servidor
Antes de buscar impacto, confirma que realmente es el backend quien realiza la conexión.
La forma más clara es utilizar un dominio o endpoint HTTP que controles y observar si recibe una petición después de enviar su URL a la aplicación.
POST /api/import HTTP/1.1
Content-Type: application/json
{
"url": "https://recurso-controlado.example/test"
}
Si tu infraestructura recibe una conexión procedente de la aplicación, has confirmado que existe una funcionalidad server-side fetch.
Esto todavía no demuestra por sí solo una vulnerabilidad SSRF explotable. Ahora debes determinar qué restricciones aplica el servidor al destino.
SSRF visible o in-band
En algunos casos, la aplicación devuelve directamente el contenido obtenido por el servidor.
Si modificas la URL y el contenido devuelto cambia en función del recurso solicitado, la aplicación actúa prácticamente como “un proxy”.
Durante la validación, presta atención a diferencias en:
- El contenido devuelto.
- Código de estado.
- Tipo y tamaño de la respuesta.
- Mensajes de error.
El objetivo es comprobar si el servidor actúa como intermediario y permite al usuario influir en el recurso que consulta.
La vulnerabilidad se vuelve relevante cuando esa capacidad permite consultar destinos o recursos que el usuario no debería poder alcanzar directamente.
Blind SSRF
En una Blind SSRF, el servidor realiza la petición hacia el recurso indicado, pero la respuesta no se devuelve.
Esto hace que la vulnerabilidad sea menos evidente y normalmente requiera confirmarla mediante efectos externos observables, por ejemplo una conexión HTTP o una consulta DNS hacia una infraestructura controlada.
El objetivo es comprobar si puedes hacer que el servidor se conecte a destinos no previstos, aunque no puedas ver la respuesta.
Durante la validación, presta atención a:
- Conexiones recibidas en infraestructura propia;
- Consultas DNS;
- Diferencias consistentes en tiempos de respuesta;
- Mensajes de error relacionados con la conexión.
La vulnerabilidad se confirma cuando existe evidencia de que el servidor realiza la petición controlada por el usuario, aunque la respuesta permanezca oculta.
Red Team OPSEC
Las pruebas de SSRF requieren especial cuidado porque las peticiones se originan desde infraestructura del objetivo y pueden alcanzar sistemas que no forman parte explícita del alcance.
Utiliza infraestructura bajo tu control
La finalidad es demostrar que el servidor puede ser utilizado como origen de peticiones hacia destinos no autorizados, no convertir la vulnerabilidad en un mecanismo general de exploración de la red interna.
CSRF (Cross-Site Request Forgery)
CSRF aparece cuando una aplicación permite que un tercero provoque acciones autenticadas en nombre de un usuario sin verificar adecuadamente que la petición fue iniciada desde un contexto autorizado.
El riesgo es especialmente relevante cuando la autenticación se mantiene automáticamente mediante cookies y el endpoint modifica estado, por ejemplo:
POST /api/account/email HTTP/1.1
Content-Type: application/x-www-form-urlencoded
email=test@example.com
Comprueba si las operaciones sensibles utilizan mecanismos como tokens anti-CSRF, validaciones de Origin o Referer, cookies con una política SameSite adecuada u otros controles equivalentes.
Validación
En una cuenta controlada, determina si la operación puede reproducirse desde un origen externo sin conocer ningún valor adicional asociado a la sesión.
No consideres vulnerable una operación únicamente porque no incluya un parámetro llamado csrf. El control puede implementarse mediante otros mecanismos.
El hallazgo se confirma cuando un origen no confiable puede provocar una acción sensible utilizando las credenciales que el navegador adjunta automáticamente.
Red Team OPSEC
Utiliza cuentas y acciones controladas. Evita provocar cambios sobre usuarios reales cuando una modificación reversible sea suficiente para demostrar el comportamiento.
CORS
CORS (Cross-Origin Resource Sharing) define qué orígenes pueden leer respuestas de una aplicación desde el navegador.
El problema aparece cuando el servidor permite que orígenes no confiables accedan a respuestas sensibles, especialmente cuando también acepta credenciales como cookies o sesiones.
Reflexión insegura del Origin
Una configuración especialmente interesante es cuando el servidor copia directamente el valor recibido en Origin.
curl -s -H "Origin: https://atacante.com" -I https://objetivo.com/api/data
Después, revisa las cabeceras CORS de la respuesta:
Access-Control-Allow-Origin: https://atacante.com
Access-Control-Allow-Credentials: true
Este comportamiento puede ser peligroso si la aplicación refleja cualquier origen proporcionado por el usuario y el endpoint devuelve información sensible asociada a la sesión.
Origen comodín (*)
Access-Control-Allow-Origin: *
Esto permite que cualquier origen lea las respuestas, pero no puede combinarse con credenciales en las peticiones CORS del navegador de la misma forma que un origen específico.
Por tanto, no implica automáticamente que un atacante pueda leer información autenticada mediante cookies.
El impacto depende del tipo de información expuesta y de si requiere autenticación.
Una respuesta con cabeceras CORS permisivas por sí sola no confirma un impacto alto.
El objetivo es demostrar que un origen externo puede leer información que debería estar disponible únicamente para la aplicación legítima.