¿Qué es la Referencia Directa Insegura a Objetos?
La referencia directa insegura a objetos (IDOR) es una vulnerabilidad de control de acceso que permite a los atacantes acceder a datos pertenecientes a otros usuarios manipulando identificadores de objetos en las solicitudes de la aplicación. Cuando su aplicación expone una clave de base de datos, nombre de archivo o ID de registro directamente a los usuarios y no verifica si el usuario solicitante es propietario de ese objeto, cualquier usuario autenticado puede ver o modificar los datos de otro usuario simplemente cambiando un número en una URL.
IDOR ha sido responsable de algunas de las mayores exposiciones de datos registradas. En 2019, First American Financial Corporation expuso más de 800 millones de imágenes que contenían números de Seguro Social y detalles de cuentas bancarias porque su aplicación permitía a cualquiera alterar un parámetro de URL para acceder a documentos pertenecientes a otros usuarios.
La falla principal es sencilla: la aplicación confirma que un usuario ha iniciado sesión (autenticación) pero nunca confirma si tiene permiso para acceder a un registro específico (autorización). Su aplicación revisa la cerradura de la puerta principal pero permite que cualquiera dentro abra todos los archivadores.
IDOR corresponde a CWE-639: Evasión de Autorización mediante Clave Controlada por el Usuario. En el contexto de API, la misma vulnerabilidad se denomina Broken Object Level Authorization, o BOLA, ocupando la posición #1 en el OWASP API1 (API1:2023). Su categoría principal, Broken Access Control, se encuentra en el puesto #1 en el OWASP Top 10 y mantiene esa posición en la edición 2025.
Antes de examinar la mecánica, es útil comprender las distintas formas que adopta IDOR y dónde encaja en los marcos de vulnerabilidad establecidos.
Tipos de Referencia Directa Insegura a Objetos
IDOR no es una falla uniforme. Se manifiesta de manera diferente según la relación de privilegios involucrada y el tipo de objeto expuesto.
IDOR Horizontal
La forma más común. Un usuario autenticado accede a objetos pertenecientes a un par en el mismo nivel de privilegio, como cambiar /api/users/123/profile a /api/users/124/profile para leer los datos de otra cuenta. No ocurre elevación de privilegios; el atacante simplemente cruza los límites de cuenta dentro del mismo nivel.
IDOR Vertical
El atacante accede a objetos que requieren privilegios superiores a los que posee: accediendo a un registro de administrador, un endpoint de configuración restringido o una función de gestión manipulando un identificador. El IDOR vertical a menudo se encadena en una escalada completa de privilegios, como en el caso de Honda eCommerce donde un investigador pasó de acceso a nivel de concesionario a administrador de plataforma.
IDOR en API (BOLA)
En APIs REST y GraphQL, la misma falla recibe un nombre distinto: Broken Object Level Authorization (BOLA). La naturaleza sin estado de las APIs hace que esta variante sea especialmente frecuente. Un solo resolver o manejador de rutas mal configurado puede exponer todos los registros de una colección a cualquier sesión autenticada.
IDOR en Recursos Estáticos
Las descargas de archivos, exportaciones y endpoints de reportes suelen pasarse por alto durante las revisiones de autorización. Si una aplicación sirve un PDF en /reports/invoice_1042.pdf sin verificar que el usuario solicitante sea propietario de esa factura, la vulnerabilidad es estructuralmente idéntica a un IDOR de registro de base de datos. Esta variante es común en plataformas de salud, finanzas y legales donde los documentos contienen datos regulados.
Cada una de estas formas corresponde a una posición distinta en los marcos de vulnerabilidad establecidos, lo que complica la clasificación de IDOR.
Clasificación OWASP de la Referencia Directa Insegura a Objetos
IDOR aparece en tres marcos de vulnerabilidad separados, cada uno reflejando una perspectiva organizacional diferente sobre la misma falla subyacente.
| Marco | Entrada | Nombre | Posición Actual |
| OWASP Top 10 (2007–2013) | A4 | Insecure Direct Object References | Independiente; obsoleto como entrada separada |
| OWASP Top 10 (2021–2025) | A01 | Broken Access Control | #1 (mapea 40 CWE, incluyendo CWE-639) |
| OWASP API Security Top 10 | API1:2023 | Broken Object Level Authorization (BOLA) | #1 (Explotabilidad fácil, Prevalencia generalizada) |
| MITRE CWE | CWE-639 | Authorization Bypass Through User-Controlled Key | 2025 CWE Top 25 |
Ubicación en OWASP Top 10
IDOR fue una entrada independiente en el Top 10 desde 2007 hasta 2013. En 2017 OWASP la consolidó bajo Broken Access Control, que ascendió al puesto #1 en 2021 y mantiene esa posición en la edición 2025, ahora mapeando 40 CWE bajo la categoría.
OWASP API Security Top 10
BOLA, el enfoque específico de API para IDOR, ha mantenido la posición API1 desde el lanzamiento del API Security Top 10 en 2019. La entrada API1:2023 califica a BOLA con la máxima puntuación tanto en explotabilidad ("Fácil") como en prevalencia ("Generalizada"), por lo que genera más hallazgos reportados que cualquier otra clase de vulnerabilidad de API.
Mapeo CWE
CWE-639 (Authorization Bypass Through User-Controlled Key) es la clasificación principal de MITRE para IDOR. Su padre es CWE-284 (Improper Access Control). El hijo más específico para implementaciones respaldadas por SQL es CWE-566 (Authorization Bypass Through User-Controlled SQL Primary Key). CWE-639 aparece en el 2025 CWE Top 25.
Comprender la taxonomía prepara el terreno para examinar cómo funciona realmente el exploit en la práctica.
¿Cómo Funciona la Referencia Directa Insegura a Objetos?
IDOR explota una brecha fundamental entre lo que su aplicación autentica y lo que autoriza. Los pasos a continuación muestran cómo un solo identificador expuesto se convierte en una brecha de datos a gran escala.
Paso 1: La Aplicación Expone una Referencia Directa a un Objeto
Su aplicación genera una URL o parámetro de API que mapea directamente a un objeto interno:
El valor 123 es la clave primaria de base de datos para un registro de usuario, expuesta directamente en la ruta de la URL.
Paso 2: El Atacante Modifica el Identificador
Un atacante cambia 123 por 124. Si la aplicación devuelve los datos del perfil del usuario 124, la vulnerabilidad está confirmada.
Paso 3: El Servidor Recupera el Objeto sin una Verificación de Autorización
La referencia OWASP proporciona un patrón de código vulnerable claro
El decorador @login_required confirma que el usuario ha iniciado sesión. No verifica si el usuario 123 debe acceder al perfil del usuario 124. Agregar una línea soluciona la vulnerabilidad:
Paso 4: La Explotación se Escala mediante Enumeración
Una vez que un atacante confirma que el patrón funciona, escribe un script para iterar a través de posibles valores de ID, convirtiendo una sola vulnerabilidad en una brecha de datos masiva. Dependiendo de la aplicación, esta enumeración puede completarse rápidamente. La velocidad de explotación es lo que transforma una sola falla de control de acceso en una brecha de datos a gran escala.
Cuatro Superficies de Ataque Principales
| Superficie | Ejemplo |
| Parámetros en la ruta de la URL | /invoices/1042 cambiado a /invoices/1043 |
| Parámetros en la cadena de consulta | ?order_id=7001 cambiado a ?order_id=7002 |
| Parámetros de archivo | ?file=report_user1.pdf cambiado a ?file=report_user2.pdf |
| Campos ocultos en el cuerpo de POST | user_id en un envío de formulario cambiado por el ID de otro usuario |
Estas superficies de ataque existen debido a causas estructurales más profundas en cómo se diseñan y construyen las aplicaciones.
Causas de la Referencia Directa Insegura a Objetos
IDOR resulta de decisiones de diseño estructural y conceptos erróneos comunes de los desarrolladores que se agravan en las arquitecturas de aplicaciones.
Falta de Autorización y Consultas sin Alcance
La causa principal son aplicaciones que toman entradas proporcionadas por el usuario para recuperar objetos sin verificar que el usuario solicitante sea propietario del registro. Esto aparece más comúnmente como consultas de base de datos sin alcance: aplicaciones que consultan la tabla completa de objetos (Order.find(order_id)) en lugar del conjunto de datos del usuario autenticado (current_user.orders.find(order_id)), exponiendo todos los registros a cualquier sesión autenticada.
Identificadores Predecibles y Exposición Directa de Claves
MITRE CWE-639 lo identifica explícitamente: los sistemas que usan IDs de registro secuenciales o fácilmente adivinables permiten a los atacantes enumerar los datos de otros usuarios incrementando valores. Exponer claves primarias de base de datos directamente en URLs o cuerpos de POST, especialmente secuencias de enteros (1, 2, 3…), crea una superficie de ataque trivialmente predecible.
El Concepto Erróneo sobre UUID
La hoja de referencia OWASP lo aborda directamente: identificadores complejos como GUIDs hacen que adivinar valores válidos sea prácticamente imposible, pero los controles de acceso siguen siendo esenciales. Si los atacantes obtienen URLs válidas mediante enlaces compartidos o respuestas de la aplicación, la aplicación aún debe bloquear el acceso no autorizado.
Arquitectura de API sin Estado
OWASP API1:2023 identifica una causa estructural específica de las APIs: el servidor depende de parámetros como IDs de objetos enviados desde el cliente para decidir qué objetos acceder. Las APIs REST y GraphQL están estructuralmente predispuestas a IDOR sin lógica de autorización explícita por solicitud.
Cuando estas causas no se abordan, las vulnerabilidades resultantes generan un impacto empresarial que va mucho más allá de la capa técnica.
Impacto y Riesgo de la Referencia Directa Insegura a Objetos
El impacto de IDOR va desde la divulgación de datos hasta la toma de control de cuentas completa, con consecuencias que se extienden a los ámbitos regulatorios, financieros y de seguridad.
Exposición de Datos a Gran Escala
Debido a que la explotación de IDOR es automatizable, un solo endpoint vulnerable puede exponer toda una base de datos. El IDOR de First American expuso más de 800 millones de imágenes. Optus perdió registros de clientes a través de un endpoint de API olvidado con controles de acceso rotos.
Sanciones Regulatorias y Financieras
Las brechas IDOR desencadenan acciones regulatorias de varios años. First American recibió sanciones de la SEC y la NYDFS. Optus también enfrentó importantes consecuencias financieras.
Toma de Control de Cuentas y Escalada de Privilegios
IDOR no se limita a la lectura de datos. En un caso documentado que involucra la plataforma eCommerce de Honda, un investigador accedió a los registros de todos los concesionarios cambiando un solo valor de ID y luego escaló a administrador de plataforma, un rol reservado para empleados de Honda.
Calificaciones de Severidad OWASP
El OWASP API Top 10 califica a BOLA con explotabilidad "Fácil" y prevalencia "Generalizada". La combinación de explotación sencilla y alta prevalencia es la razón por la que ocupa la posición #1.
Estas calificaciones de severidad reflejan los métodos que los atacantes utilizan para explotar IDOR a gran escala.
Cómo Explotan los Atacantes la Referencia Directa Insegura a Objetos
La explotación de IDOR sigue un flujo de trabajo estructurado que requiere una sofisticación técnica mínima.
Sustitución de Parámetros
El atacante modifica un identificador por el valor de otro usuario y observa la respuesta. Cambiar /api/users/123/profile a /api/users/124/profile y recibir una respuesta 200 OK en lugar de 403 Forbidden confirma la vulnerabilidad.
Enumeración Automatizada
Una vez confirmada, los atacantes escalan el exploit usando el módulo Intruder de Burp Suite, OWASP ZAP o scripts personalizados para iterar por todos los valores de ID posibles. La documentación de OWASP API describe cómo un simple script que manipula IDs en una URL otorga acceso a miles de registros.
Explotación Encadenada
Los atacantes combinan IDOR con otras vulnerabilidades. El caso de Honda eCommerce demuestra acceso horizontal a datos encadenado con escalada vertical de privilegios. La plataforma McHire de McDonald's combinó un IDOR con credenciales por defecto para agravar la exposición.
Acceso Horizontal y Vertical
La guía de control de acceso OWASP aclara la distinción. IDOR habilita más comúnmente la escalada horizontal de privilegios: el Usuario A accede a los datos del Usuario B en el mismo nivel de privilegio. Menos comúnmente, IDOR permite escalada vertical: un usuario estándar obtiene acceso de administrador.
La simplicidad de estas técnicas significa que prácticamente cualquier aplicación que maneje datos de usuario puede convertirse en objetivo.
¿Quiénes se ven afectados por la Referencia Directa Insegura a Objetos?
IDOR afecta a cualquier aplicación que utilice identificadores controlables por el usuario para acceder a objetos sin verificaciones de autorización por solicitud.
Arquitecturas de Aplicación de Alto Riesgo
El riesgo de IDOR se amplifica por ciertos patrones estructurales que exponen referencias a objetos más ampliamente o facilitan omitir verificaciones de autorización.
- APIs REST con patrones de URL basados en recursos. Cualquier API que siga convenciones
/resource/{id}tiene exposición estructural a IDOR por diseño. - APIs GraphQL. El acceso a objetos basado en argumentos crea la misma vulnerabilidad cuando los resolvers omiten verificaciones de propiedad.
- Aplicaciones SaaS multi-inquilino. Un usuario en un inquilino manipula IDs para acceder a los datos de otro inquilino.
- Backends de API para IoT y móviles. Flujos de autenticación complejos y gestión limitada de estado del lado del servidor aumentan la exposición a BOLA.
- Plataformas de comercio electrónico. IDs de pedidos, facturas y referencias de cuentas de clientes son objetivos de alto valor.
Lo que une a todas estas arquitecturas es que el acceso a objetos está impulsado por identificadores que controla el cliente, sin que el servidor realice una verificación de propiedad antes de devolver los datos.
Industrias de Alto Riesgo
Las industrias más expuestas son aquellas donde las referencias a objetos mapean directamente a registros sensibles, datos regulados o sistemas físicos.
- Salud: CVE-2024-28320 (Hospital Management System, CVSS 7.6) permitió la lectura y modificación de datos de pacientes.
- Servicios financieros: Las plataformas de pago y compañías de títulos enfrentan tanto exposición de datos como riesgo regulatorio.
- Gobierno: Según HackerOne, los programas gubernamentales reportan IDOR como un problema recurrente.
- Automotriz: El caso Pandora/Viper y CVE-2025-11690 confirman el riesgo real para sistemas de vehículos.
Las brechas documentadas en estas industrias ilustran las consecuencias reales de dejar IDOR sin abordar.
Ejemplos Reales de Referencia Directa Insegura a Objetos
Los siguientes casos muestran cómo IDOR se ha presentado en diferentes industrias y tipos de aplicaciones. Cada incidente se remonta a la misma falla raíz: identificadores proporcionados por el usuario que llegan a un servidor que nunca verificó si el solicitante era propietario del objeto devuelto.
First American Financial Corporation (2019)
La aplicación EaglePro de First American permitía a cualquier usuario alterar un parámetro de URL y acceder a documentos de depósito en garantía y títulos pertenecientes a otros usuarios. La vulnerabilidad, introducida en 2014, persistió durante cinco años. Se expusieron más de 800 millones de imágenes, incluidos números de Seguro Social y documentos de pago hipotecario. Las sanciones regulatorias están documentadas en el archivo de la SEC y el archivo de la NYDFS. CISA, NSA y la Dirección de Señales de Australia citaron este caso en su aviso conjunto sobre IDOR.
Brecha de Datos de Optus (2022)
Un error de codificación de 2018 rompió los controles de acceso en un endpoint de API de Optus. Optus corrigió el error en su dominio principal en 2021 pero dejó un dominio olvidado y expuesto a Internet sin parchear. En septiembre de 2022, un atacante explotó el control de acceso roto para exfiltrar registros de clientes, incluidos números de identificación personal válidos. La Autoridad de Comunicaciones y Medios de Australia (ACMA) confirmó que el ataque "no fue altamente sofisticado" y se realizó mediante "un simple proceso de prueba y error". Sigue siendo la mayor brecha de datos de Australia.
Chatbot McHire de McDonald's (2025)
Los investigadores de seguridad Ian Carroll y Sam Curry descubrieron un IDOR en la API del chatbot McHire de Paradox.ai utilizada por McDonald's. Al decrementar un entero lead_id en el endpoint interno /api/lead/cem-xhr, recuperaron transcripciones completas de chat, detalles de contacto y tokens de sesión pertenecientes a otros solicitantes sin verificación de autorización. El lead_id de su propia aplicación era 64,185,742, lo que indica la escala de registros potencialmente accesibles. La vulnerabilidad se divulgó el 30 de junio de 2025 y se corrigió el mismo día.
Pandora y Viper Smart Car Alarms (2019)
Pen Test Partners encontró vulnerabilidades IDOR en APIs de alarmas inteligentes para automóviles que permitían la toma de control total de cuentas en flotas de vehículos. Los atacantes podían cambiar contraseñas o direcciones de correo electrónico de cuentas, obteniendo control físico sobre los vehículos. Los investigadores estimaron que aproximadamente tres millones de vehículos de alta gama estuvieron expuestos antes de que los proveedores corrigieran las fallas en pocos días tras la divulgación.
Señal de Bug Bounty
IDOR es un hallazgo de alto valor constante en plataformas de bug bounty. Un reporte de PayPal obtuvo una recompensa notable en HackerOne, y datos de HackerOne muestran que IDOR sigue siendo una clase de vulnerabilidad recurrente.
Estos incidentes abarcan más de una década de presencia de IDOR en marcos de vulnerabilidad principales y brechas reales.
Línea de Tiempo e Historia de la Referencia Directa Insegura a Objetos
IDOR ha sido parte del panorama formal de seguridad durante casi dos décadas. La siguiente línea de tiempo rastrea su evolución desde una categoría nombrada independiente hasta un concepto fundamental integrado en múltiples marcos, y su continua expansión a infraestructuras más nuevas como APIs, IoT y sistemas de IA.
| Período | Hito |
| 2007 | OWASP introdujo el término "IDOR" en el Top Ten como categoría independiente en A4. |
| 2013-2014 | Último año como categoría independiente OWASP (A4). Se introduce el defecto IDOR de First American |
| 2017 | IDOR se consolida en Broken Access Control en A5. |
| 2019 | OWASP API Security Top 10 introduce BOLA como API1. Divulgación de First American. Documentación de la exposición Pandora/Viper. |
| 2021 | Broken Access Control en el puesto #1 del OWASP Top 10. |
| 2022 | Brecha de Optus, la mayor brecha de datos de Australia. |
| 2023 | CISA/NSA/ACSC publican aviso conjunto AA23-208A sobre IDOR. BOLA se mantiene en API1:2023. |
| 2025 | Broken Access Control se mantiene en el puesto #1, mapeando 40 CWE. CWE-639 listado en el 2025 CWE Top 25. IDOR de McHire de McDonald's divulgado por Ian Carroll y Sam Curry. |
| 2024-2026 | IDOR se expande a infraestructura de IA/LLM (CVE-2025-4962), telemática de vehículos (CVE-2025-11690) y IAM empresarial (CVE-2024-56404). HackerOne confirma el aumento de reportes de IDOR mientras XSS y SQLi disminuyen. |
Con la persistencia de IDOR a lo largo de casi dos décadas de seguimiento de vulnerabilidades, necesita métodos confiables para encontrarlo en sus propias aplicaciones.
Cómo Detectar la Referencia Directa Insegura a Objetos
IDOR es difícil de encontrar solo con herramientas porque requiere razonar sobre la propiedad de objetos y la lógica de negocio, no solo hacer coincidencias de patrones en los códigos de respuesta.
Pruebas de Penetración Manual (requerido)
El OWASP WSTG define el procedimiento de prueba:
- Mapear todas las ubicaciones donde la entrada del usuario referencia objetos directamente.
- Modificar el valor del parámetro utilizado para referenciar objetos.
- Evaluar si puede recuperar objetos pertenecientes a otros usuarios o eludir la autorización.
- Probar diferentes métodos HTTP y patrones de acceso masivo.
Las pruebas manuales son el único método que razona sobre la intención de autorización en lugar de solo manipulación de parámetros. Ningún escáner puede sustituir de manera confiable a un tester que entiende qué debe y no debe poder acceder cada rol de usuario.
Herramientas de Pruebas de Seguridad de Aplicaciones
Las herramientas DAST como OWASP ZAP y Burp Suite pueden encontrar IDOR cuando se configuran con cuentas de prueba multiusuario y mapeos de IDs de objetos entre usuarios. Las configuraciones predeterminadas de los escáneres no detectarán IDOR. Las herramientas SAST pueden señalar endpoints que carecen de llamadas a funciones de autorización pero no pueden determinar si la lógica de autorización es semánticamente correcta en tiempo de ejecución.
Monitoreo de Comportamiento en Tiempo de Ejecución
Este es el único control en producción que puede encontrar IDOR de manera realista en producción. Busque estas señales:
- Solicitudes secuenciales o con patrón de enumeración a endpoints de referencia de objetos desde una sola sesión
- Solicitudes autenticadas que devuelven 200 OK para IDs de objetos que no pertenecen al usuario solicitante
- Solicitudes de referencia de objetos de alto volumen entre varias cuentas de usuario
A diferencia de las pruebas previas al despliegue, el monitoreo de comportamiento funciona continuamente en producción, donde realmente ocurre la explotación. Es el único control que puede detectar IDOR siendo abusado activamente contra datos en vivo.
Revisión Segura de Código
Según la hoja de referencia de autorización, la revisión de código debe verificar que el permiso se valide en cada solicitud y que el control de acceso se implemente globalmente en lugar de por método. Preste especial atención a los endpoints que aceptan identificadores proporcionados por el usuario y trace la ruta del código desde la entrada del parámetro hasta la consulta de base de datos y la respuesta. Cualquier ruta que recupere un objeto sin limitar la consulta a los permisos del usuario autenticado representa un riesgo IDOR confirmado.
Encontrar IDOR es solo el primer paso. Prevenirlo requiere controles integrados en todo su ciclo de desarrollo y despliegue.
Cómo Prevenir la Referencia Directa Insegura a Objetos
La prevención requiere un enfoque en capas que abarque diseño, desarrollo, pruebas y monitoreo en tiempo de ejecución.
Fase de Diseño: Modele la Autorización en cada función
Incluya el control de acceso roto en su análisis de superficie de ataque durante el diseño de funciones. Defina funciones de autorización explícitas (patrones canAccess, isOwner) antes de escribir código.
Fase de Desarrollo: Haga cumplir la Autorización del Lado del Servidor en cada acceso a objeto
La hoja de referencia IDOR especifica estos controles:
- Implemente verificaciones de control de acceso para cada objeto al que un usuario intente acceder. Determine el usuario autenticado a partir de la información de sesión, no de identificadores proporcionados por el cliente. Haga cumplir las verificaciones mediante middleware centralizado en lugar de lógica por método.
- Limite las consultas de base de datos al conjunto de datos accesible por el usuario autenticado:
Utilice mapas de referencia indirecta que traduzcan valores externos ofuscados a IDs internos de base de datos, combinados con verificaciones de autorización.
Adopte UUIDs o valores aleatorios largos como identificadores públicos. Esto es una capa de defensa en profundidad, no un control principal.
Evite el cifrado de identificadores. La hoja de referencia OWASP indica que esto "puede ser difícil de implementar de forma segura".
- Haga cumplir la autorización en recursos estáticos, una superficie frecuentemente pasada por alto según la hoja de referencia de autorización.
Estos controles funcionan porque hacen cumplir la propiedad en la capa de datos en lugar de confiar en valores proporcionados por el cliente. Un atacante que manipula un parámetro se encuentra con una verificación de autorización en lugar de una consulta exitosa.
Fase de Pruebas: Pruebas de Autorización Multiusuario
Ejecute escaneos DAST con configuraciones multiusuario que prueben el acceso entre cuentas. Incluya reglas SAST que señalen endpoints que carecen de llamadas a funciones de autorización. Priorice las pruebas manuales de penetración para IDOR de lógica de negocio.
Fase de Ejecución: Monitoreo de Comportamiento de API
Implemente monitoreo de comportamiento que establezca una línea base de patrones normales de acceso a API y marque accesos anómalos a objetos. La tecnología Storyline de SentinelOne puede reconstruir la secuencia completa de interacciones API y el contexto de identidad alrededor de patrones de acceso sospechosos, proporcionando a su equipo la línea de tiempo forense necesaria para confirmar o descartar la explotación de IDOR.
Implementar estos controles de manera efectiva requiere la combinación adecuada de pruebas de seguridad de aplicaciones y herramientas de monitoreo en tiempo de ejecución.
Herramientas para Detección y Prevención
Ninguna herramienta cubre IDOR completamente. La cobertura efectiva requiere una combinación en capas de escaneo en tiempo de desarrollo, monitoreo en tiempo de ejecución y validación manual a lo largo del ciclo de vida de la aplicación. Las herramientas a continuación abordan diferentes fases, cada una con cobertura y limitaciones distintas.
Herramientas de Pruebas de Seguridad de Aplicaciones
| Tipo de Herramienta | Capacidad | Cobertura IDOR | Limitación |
| DAST (OWASP ZAP, Burp Suite) | Prueba aplicaciones en ejecución vía HTTP/S | Encuentra IDOR con configuraciones multiusuario | Requiere configuración manual de escenarios de prueba entre cuentas |
| SAST (SonarQube, Checkmarx) | Análisis de código fuente (caja blanca) | Señala patrones de llamadas de autorización faltantes | No puede verificar la corrección semántica de la lógica de autorización |
| IAST (Contrast Security) | Agente en la aplicación durante pruebas QA | Contexto de comportamiento en tiempo de ejecución con menos falsos positivos | Requiere entornos de prueba instrumentados |
| Pen Testing Manual | Lógica de negocio, escenarios multiusuario | Único método confiable para IDOR complejo | Intensivo en tiempo, requiere testers capacitados |
Seguridad de API y Monitoreo de Comportamiento
Las herramientas de monitoreo de comportamiento de API construyen líneas base de patrones normales de acceso y marcan anomalías. Estos son los únicos controles en tiempo de ejecución que pueden encontrar explotación de IDOR en producción, porque las solicitudes IDOR son sintácticamente idénticas al tráfico legítimo.
Vulnerabilidades Relacionadas
IDOR pertenece a la familia más amplia de Broken Access Control. Comprender su relación con tipos de vulnerabilidad relacionados le ayuda a priorizar la remediación.
- Broken Object Level Authorization (BOLA), API1:2023. Tanto IDOR como BOLA corresponden a CWE-639. BOLA es el enfoque específico de API para la misma falla subyacente.
- Broken Function Level Authorization (BFLA), API5:2023 / CWE-285. Mientras que IDOR apunta a objetos de datos (qué registros puede acceder), BFLA apunta a funciones de API (qué operaciones puede realizar), permitiendo principalmente escalada vertical de privilegios.
- Forced Browsing (CWE-425). Elude la navegación y controles a nivel de página para acceder directamente a páginas restringidas, listado como ejemplo concreto de Broken Access Control.
- SQL Primary Key Authorization Bypass (CWE-566). Hijo directo de CWE-639, es el CWE más específico para implementaciones IDOR respaldadas por SQL.
- Escalada Vertical de Privilegios (CWE-269 / CWE-285). IDOR puede encadenarse en escalada de privilegios cuando un atacante modifica un identificador para acceder a funciones administrativas, como se demostró en el caso de Honda eCommerce.
Varios CVE específicos demuestran cómo estos patrones de vulnerabilidad relacionados aparecen en sistemas en producción.
CVEs Relacionados
| ID CVE | Descripción | Severidad | Producto Afectado | Año |
| CWE-639 IDOR en módulos API tab-doc de Tableau Server; un atacante en la red adyacente manipula claves controladas por el usuario para evadir la autorización y acceder a clústeres de bases de datos de producción | ALTA | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| CWE-639 IDOR en el comando set-initial-sql tabdoc de Tableau Server; usuarios autenticados de bajo privilegio manipulan parámetros controlados por el usuario para acceder a clústeres de bases de datos de producción | ALTA | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| CWE-639 IDOR en el manejo de recursos de hilos de Chainlit; usuarios autenticados suministran el ID de hilo de otro usuario para acceder a datos de conversación sin verificación de propiedad | MEDIA | Chainlit | 2025 | |
| CWE-639 IDOR en el plugin WordPress Five Star Restaurant Reservations; atacantes no autenticados manipulan identificadores de reserva para acceder, modificar o eliminar registros de otros usuarios | MEDIA | Five Star Restaurant Reservations WP plugin (≤2.7.8) | 2025 | |
| IDOR en One Identity Identity Manager permite escalada de privilegios en instalaciones on-premise; el atacante manipula referencias a objetos para asumir permisos más allá de su rol asignado | CRÍTICA | One Identity Identity Manager 9.x (<9.3) | 2024 | |
| IDOR no autenticado en la herramienta SO Planning; cuando la vista pública está habilitada, un atacante accede a toda la base de datos subyacente solicitando directamente el endpoint de exportación, descargándola como CSV | CRÍTICA | SO Planning (<1.52.02) | 2024 | |
| IDOR no autenticado en WooCommerce Stripe Payment Gateway; la falta de verificación de propiedad de pedido expone nombre de facturación, correo electrónico y dirección de cualquier pedido a usuarios no autenticados en más de 900,000 instalaciones activas | ALTA | WooCommerce Stripe Payment Gateway WP plugin (≤7.4.0) | 2023 | |
| CWE-639 IDOR en la plataforma de imágenes médicas ExtremePacs Extreme XDS; la manipulación de claves controladas por el usuario permite acceder a registros de imágenes de otros pacientes sin autorización | ALTA | ExtremePacs Extreme XDS (<3914) | 2023 | |
| IDOR en el servidor backend compartido de stalkerware expuso mensajes de texto, registros de llamadas, fotos y datos de geolocalización de cientos de miles de dispositivos; citado por nombre en el Aviso CISA/NSA/ACSC AA23-208A | ALTA | 1byte / Múltiples apps stalkerware | 2022 | |
| IDOR en la función de restablecimiento de contraseña de Telos Alliance Omnia MPX Node; el atacante suministra el identificador de cuenta de cualquier usuario para restablecer su contraseña, permitiendo la toma de control total de la cuenta, incluidas cuentas de Administrador | ALTA | Telos Alliance Omnia MPX Node (1.0.0–1.4.x) | 2022 |
Ciberseguridad impulsada por la IA
Mejore su postura de seguridad con detección en tiempo real, respuesta a velocidad de máquina y visibilidad total de todo su entorno digital.
DemostraciónConclusión
La referencia directa insegura a objetos sigue siendo una de las fallas de seguridad web más explotadas porque rompe la autorización a nivel de objeto, no solo el manejo de entradas. Si su aplicación confía en identificadores proporcionados por el usuario sin verificar la propiedad, un pequeño cambio en la URL puede convertirse en una exposición de datos a gran escala.
Usted reduce ese riesgo haciendo cumplir la autorización en cada acceso a objeto, probando en múltiples contextos de usuario y monitoreando el abuso en producción.
Preguntas frecuentes
IDOR es una falla en la aplicación de la propiedad de los registros. Si su servidor no verifica que un usuario pueda acceder a un objeto específico, cambiar un nombre de archivo, número de pedido o ID de perfil puede exponer o modificar los datos de otra persona. En la práctica, IDOR es ante todo un problema de autorización y en segundo lugar un problema de manipulación de parámetros.
Sí. Materiales antiguos de OWASP pueden llamarla IDOR, mientras que las guías más recientes la incluyen bajo Broken Access Control. Los equipos enfocados en API suelen denominar la misma falla como BOLA.
Diferentes etiquetas apuntan a la misma causa raíz: ausencia de autorización a nivel de objeto.
Sí. Un atacante normalmente solo necesita un endpoint accesible y una forma válida de enviar solicitudes. Por lo general, no necesita ejecución de código ni entrega de malware.
Una vez que funciona un patrón de referencia de objeto, la explotación puede expandirse mediante solicitudes automatizadas, por lo que los dominios olvidados, versiones antiguas de API y backends móviles expuestos son especialmente riesgosos.
Las aplicaciones son más vulnerables cuando la búsqueda de objetos depende de la entrada del cliente. El riesgo aumenta en sistemas que exponen muchas referencias a objetos, comparten infraestructura entre inquilinos o dependen de API sin estado que confían repetidamente en los ID enviados por el cliente. Las operaciones de alto valor incluyen obtener, actualizar, exportar o eliminar registros vinculados a usuarios.
Los atacantes suelen comenzar donde la aplicación revela cómo nombra los objetos: un ID visible en una URL, campo oculto de formulario, cuerpo JSON o respuesta de API. Luego intercambian valores, comparan respuestas y prueban diferentes métodos o contextos de cuenta.
Incluso pequeñas diferencias en los códigos de estado, tamaños de respuesta o campos devueltos pueden confirmar el acceso explotable a objetos.
Los primeros indicios suelen ser conductuales. Observe si una identidad autenticada solicita muchos ID de objetos, cruza los límites esperados de cuentas o inquilinos, o accede a registros en una secuencia que no coincide con el comportamiento normal del usuario.
Debido a que IDOR suele ocultarse dentro de tráfico HTTP válido, el contexto importa más que la sintaxis.
Su gravedad proviene tanto de la escala y confiabilidad como del CVSS puro. Muchas vulnerabilidades requieren cadenas de explotación frágiles; IDOR suele funcionar con el comportamiento normal de la aplicación una vez que falta la verificación de propiedad.
Puede ir desde una filtración limitada de datos hasta la toma de control de cuentas o escalamiento de privilegios, según el objeto expuesto.
A veces. Si el objeto expuesto controla restablecimientos de contraseña, configuraciones administrativas, límites de inquilinos o acciones de flujo de trabajo, IDOR puede convertirse en el primer paso de una toma de control mayor.
La función empresarial del objeto determina si la falla permanece local a un registro o se expande a un incidente en toda la plataforma.
No por defecto. Las herramientas pueden encontrar entradas y reproducir solicitudes, pero IDOR requiere comprender quién debe ser propietario de cada objeto y cómo difieren los roles entre sesiones.
El enfoque más eficaz combina automatización con datos de prueba multiusuario preparados y validación manual. En producción, la monitorización de comportamiento es más realista que depender solo de escáneres.
Los sectores de mayor riesgo son aquellos donde las referencias a objetos se asignan directamente a registros sensibles, datos regulados o efectos en el mundo físico. En la práctica, eso incluye registros de salud, documentos financieros, datos gubernamentales, sistemas automotrices y activos de gestión de identidades.
En estos entornos, cada acceso no autorizado a objetos puede conllevar consecuencias significativas de privacidad, cumplimiento, fraude o seguridad.
