⌘K
ENES
GitHub
conceptSeguridad Web~3 min de lecturaActualizado Apr 29, 2026#cybersecurity#web-security#access-control#idor

Insecure Direct Object Reference (IDOR)

Definición

IDOR es una clase de falla de autorización donde un atacante puede acceder o actuar sobre un objeto manipulando una referencia directa como un ID, nombre de archivo, clave o path.

Por qué importa

IDOR es una de las clases de bug de mayor valor en aplicaciones reales porque:

  • las referencias a objetos están por todos lados
  • el camino de explotación suele ser simple
  • el impacto suele ser acceso no autorizado real, no solo rarezas teóricas

Se entiende mejor como el encuadre clásico de web/appsec de la falla de autorización a nivel de objeto.

Esta nota debería quedar distinta de la Broken Object-Level Authorization del lado de API, aunque están muy relacionadas.

Cómo funciona

El mecanismo es:

  1. la aplicación expone una referencia a un objeto
  2. el servidor usa esa referencia para recuperar o modificar el objeto
  3. el servidor no logra verificar que el usuario actual tenga permitido acceder a ese objeto

La vulnerabilidad no es "el ID es adivinable". La vulnerabilidad es "la autorización no se impone correctamente".

Incluso los UUIDs no resuelven IDOR si faltan los chequeos de propiedad o de acceso.

Técnicas / patrones

Los atacantes normalmente testean IDOR modificando:

  • IDs numéricos en paths
  • UUIDs en URLs o JSON
  • nombres de archivo y referencias a documentos
  • referencias de download/export
  • valores de formulario ocultos
  • rutas de frontend solo-mobile o alternativas
  • referencias indirectas que igual mapean de forma predecible a objetos reales

Flujo de trabajo típico:

  • logueate como usuario A
  • capturá una request al objeto A
  • cambiá solo la referencia al objeto
  • reproducila contra el objeto B
  • observá diferencias de lectura, escritura o metadata

Variantes y bypasses

IDOR de lectura

Lectura no autorizada del objeto de otro usuario.

IDOR de escritura

Modificación no autorizada del objeto de otro usuario.

IDOR de borrado / destructivo

Acceso a nivel de objeto más acción destructiva.

Solapamiento con IDOR de función oculta

A veces el problema no es solo el acceso al objeto, sino también llamar a una ruta que la UI oculta. Eso empieza a solaparse con Control de acceso roto o Broken Function-Level Authorization.

IDOR de workflow multi-paso

La referencia al objeto es segura en un paso pero se vuelve explotable más adelante en el flujo.

Malentendidos sobre referencias indirectas

Las apps a veces usan:

  • UUIDs
  • tokens opacos
  • identificadores envueltos en base64

Estos igual pueden ser explotables si la autorización del lado del servidor es débil.

Impacto

El impacto suele ser muy directo:

  • acceder a los datos de otro usuario
  • cambiar la configuración de otro usuario
  • descargar los archivos de otro usuario
  • escalar a través del acceso al estado de un objeto privilegiado
  • destruir o corromper registros

El impacto se vuelve crítico cuando los objetos son:

  • financieros
  • relacionados con identidad
  • de cara al admin
  • accesibles en bulk
  • fáciles de enumerar

Detección y defensa

Ordenado por efectividad:

  1. Autorización del lado del servidor en cada acceso a objeto
    Verificá siempre el derecho del llamante a ese objeto específico.
  2. Separá claramente la recuperación de objeto de la autorización de objeto
    No asumas "si la ruta está autenticada, el objeto es seguro".
  3. Negá por defecto
    La propiedad o el acceso deben probarse, no asumirse.
  4. Logueá los intentos de acceso a objetos sospechosos
    Especialmente patrones de acceso a través de objetos adyacentes o no relacionados.
  5. Usá referencias indirectas solo como fricción secundaria
    No son un control de autorización primario.
  6. Testeá tanto los caminos de lectura como de escritura
    Muchos equipos arreglan uno y se pierden el otro.

Ejemplos prácticos

  • cambiar /invoice/1001 por /invoice/1002
  • intercambiar un ID de documento en una request de download
  • modificar un ticket de soporte u objeto de cuenta no poseído por el usuario actual
  • cambiar un ID oculto de proyecto/miembro/recurso en un formulario o llamada de API

Notas relacionadas

Notas atómicas futuras sugeridas

  • Patrones de chequeo de propiedad de objeto
  • Malentendidos sobre referencias indirectas

Referencias

  • Foundational: OWASP WSTG authorization testing — https://owasp.org/www-project-web-security-testing-guide/latest/
  • Foundational: OWASP Top 10 Broken Access Control — https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
  • Testing / Lab: PortSwigger IDOR topic — https://portswigger.net/web-security/access-control/idor

Notas relacionadas

Seguridad WebControl de acceso rotoEl control de acceso roto (broken access control) ocurre cuando una aplicación no logra imponer a qué puede acceder o qué puede hacer un llamante. Seguridad WebFallas de autenticaciónLas fallas de autenticación son debilidades en cómo una aplicación verifica la identidad. Incluyen lógica de login débil, enumeración de usuarios, flujos de MFA rotos, debilidades en el reset de contraseña, exposición a credential stuffing y supuestos defectuosos alrededor de la emisión de sesiones/tokens. Seguridad WebBot Detection SignalsLas señales de detección de bots son atributos observables de requests HTTP, sesiones de navegador y patrones de comportamiento que diferencian el tráfico automatizado del tráfico humano legítimo. No existe una señal única suficiente — la detección efectiva puntúa múltiples familias de señales en conjunto. Seguridad WebFronteras de seguridad del navegadorLas "fronteras de seguridad del navegador" son el stack en capas de fronteras de aislamiento que un navegador moderno impone entre contenido web — no una sola regla sino cinco fronteras que operan a distintas granularidades: origen (acceso de script), sitio (estado), proceso (memoria), agent cluster (APIs poderosas) y partición de almacenamiento (estado cross-site). La política del mismo origen es la más interna de estas; las otras se agregaron (mayormente 2019–2025, aceleradas por Spectre y por el trabajo de privacidad) porque el aislamiento a nivel de origen por sí solo ya no aguanta contra los canales laterales especulativos y el tracking cross-site. Un "bypass de seguridad del navegador" es casi siempre encontrar la única capa de este stack que no aguantó. Seguridad WebBusiness Logic VulnerabilitiesLas vulnerabilidades de lógica de negocio son fallas en el flujo de trabajo previsto, suposiciones, invariantes o diseño de reglas de una aplicación, donde el sistema se comporta como fue codificado pero no de forma segura según la intención. Seguridad WebClickjackingClickjacking es un ataque de redirección de UI donde un atacante embebe una página objetivo en un frame y engaña al usuario para que haga clic o escriba en la UI real del objetivo mientras cree que está interactuando con otra página.