La vulnerabilidad IDOR (Insecure Direct Object Reference) constituye por sí misma un incumplimiento de las obligaciones de seguridad y protección de datos personales, haya existido o no un ataque demostrable.
1. ¿Qué es IDOR?
IDOR es un fallo de control de acceso en el que un sistema permite acceder a datos personales simplemente modificando un identificador o token en una URL o en un parámetro, sin autenticación ni autorización.
Puede consultarse una explicación técnica en:
- OWASP — Broken Access Control / IDOR
- Ejemplo práctico del caso First American Financial, por modificación de un dígito en enlaces para acceder a otros documentos: «First American Financial exposed data in millions of mortgage documents, report says».
IDOR (Insecure Direct Object Reference) está categorizado formalmente por MITRE como CWE‑639 – Authorization Bypass Through User‑Controlled Key, una debilidad de control de acceso que permite a un tercero acceder a datos personales simplemente manipulando un identificador presente en la URL o en los parámetros de una petición.
IDOR es, por diseño, una configuración que elimina los controles de acceso exigidos por la normativa y expone datos personales a cualquier tercero que obtenga la URL.
2. Un IDOR es un incumplimiento del RGPD, incluso sin evidencia de explotación
El RGPD, art. 32, exige medidas técnicas y organizativas adecuadas para garantizar la confidencialidad e integridad de los datos personales.
Cuando existe un IDOR:
- La empresa no puede autenticar al usuario que accede, por lo que no puede garantizar la confidencialidad.
- No puede acreditar que los datos solo han sido consultados por personas autorizadas.
- No puede saber si el enlace ha sido reenviado, indexado, interceptado o expuesto.
- No puede separar qué personas han sido afectadas de cuáles no, pues no existe trazabilidad.
Por tanto, la infracción existe aunque no se detecten accesos indebidos.
3. La longitud o complejidad de la URL no es una medida de seguridad
Una URL larga no equivale a una medida de seguridad válida.
Los enlaces:
- Pueden reenviarse accidental o voluntariamente.
- Pueden quedar almacenados en historiales, logs, correos, backups y sistemas intermedios.
- Pueden quedar expuestos si el dispositivo del cliente está comprometido.
- Pueden descubrirse si los identificadores son secuenciales, como ocurrió en el caso First American (885 millones de documentos expuestos).
El uso de URLs sin autenticación vulnera los principios de seguridad desde el diseño (art. 25 RGPD) y seguridad del tratamiento (art. 32 RGPD).
4. La causa real del IDOR: falta de cumplimiento desde el inicio
IDOR no suele ser un fallo “técnico” aislado.
En la práctica, deriva casi siempre de que un departamento decide:
- Crear o desplegar una solución sin involucrar a Cumplimiento,
- sin consultar a Seguridad de la Información,
- y sin solicitar validación del Delegado de Protección de Datos.
La presión del negocio, la urgencia o la falsa creencia de que “hacerlo bien es más lento”, conduce a decisiones que ignoran obligaciones legales y éticas.
Esto no solo es ilegal, sino una falta de ética profesional.
5. Si el IDOR ha estado activo durante semanas, meses o años
Cuando se descubre un IDOR que ha permanecido accesible durante un tiempo prolongado:
- La empresa no puede garantizar que no ha habido accesos indebidos.
- La empresa tiene responsabilidad proactiva para corregirlo, documentarlo y evaluar el riesgo.
- En caso de exponer datos personales, debe aplicarse la Guía de gestión de brechas de la AEPD.
- Si existe riesgo para los derechos y libertades, debe notificarse la violación de seguridad a la AEPD (art. 33 RGPD).
- Si el riesgo es alto, debe comunicarse a los afectados (art. 34 RGPD).
- Es legítimo ampliar la notificación si posteriormente surgen nuevas evidencias.
Si la empresa notifica dentro del plazo previsto y finalmente, a través de la investigación analítica, advierte que no existió riesgo para los derechos y libertades de las personas física, deberá notificárselo así a la AEPD. Esta habría sido una acción correcta de responsabilidad proactiva por parte de la empresa, que se posicionaría a la vanguardia de cumplimiento honesto.
6. Casos reales donde IDOR fue sancionado o investigado
Las autoridades europeas vienen sancionando sistemáticamente la ausencia de controles de acceso adecuados, incluso cuando no se demuestra un ataque efectivo, porque el riesgo para los derechos y libertades deriva directamente del diseño inseguro.
Caso First American Financial (2019) — 885 millones de documentos expuestos
- Exposición masiva por modificación de un número en la URL: «First American Financial exposed data in millions of mortgage documents, report says».
- Investigación de la SEC por control interno deficiente.
- Análisis técnico detallado.
McDonald’s / Paradox.ai (2025) — IDOR + credenciales por defecto
- Fallo de seguridad en la IA de selección de McDonald’s expone datos de millones de solicitantes. (INCIBE-CERT)
- Exposición potencial de millones de solicitudes mediante IDOR en API interna.
- Acceso masivo a chats y datos personales (nombre, email, teléfono, pruebas, etc.).
Estos casos subrayan que IDOR es uno de los fallos más graves que una organización puede tener, especialmente cuando afecta a información personal.
7. Responsabilidad proactiva
La responsabilidad proactiva exige que:
- Las empresas no esperen a ser sancionadas para corregir sus sistemas.
- Se adopten medidas técnicas adecuadas:
autenticación robusta, autorización por objeto, tokens firmados y caducados, no uso de IDs secuenciales, cifrado, logs verificables, etc. - Se revisen y auditen aplicaciones de terceros antes de su despliegue.
- Se informe de forma transparente a las personas afectadas cuando proceda.
La responsabilidad proactiva (accountability) exige que la organización pueda demostrar, y no solo declarar, que ha implantado medidas adecuadas para evitar fallos como IDOR en todas las fases del ciclo de vida del dato. No es un principio declarativo: obliga a anticipar riesgos, documentar decisiones y justificar los controles aplicados. La existencia de un IDOR evidencia que no se han aplicado medidas adecuadas desde el diseño, lo que constituye un incumplimiento estructural del art. 5.2 RGPD.
El fallo IDOR vulnera directamente controles esenciales de ISO 27001, como los de A.8.2 y A.8.3 (gestión del acceso y autorización) y A.14 (seguridad en el desarrollo, revisiones de diseño y validación de controles de acceso). Asimismo, incumple ISO 27701, que exige a responsables y encargados garantizar que el acceso a datos personales esté limitado, auditado y protegido mediante mecanismos robustos de autorización por objeto. Un IDOR demuestra que estos controles no se han aplicado ni verificado.
La responsabilidad proactiva alcanza también al software utilizado y a toda la cadena de proveedores. La organización debe asegurar que aplicaciones internas y soluciones de terceros incorporen controles de autenticación y autorización adecuados, sometiéndolos a pruebas de seguridad, auditorías y revisiones de código o APIs. Delegar el tratamiento en un proveedor no elimina la responsabilidad: un IDOR en un sistema externo constituye igualmente un incumplimiento del responsable del tratamiento si no ha verificado previamente la adecuación de las medidas.
8. Conclusión
En definitiva, una vulnerabilidad IDOR no es un error menor ni un incidente hipotético: es la evidencia objetiva de que la organización no ha aplicado los principios de seguridad y protección de datos que exige la normativa y el sentido común profesional.
En un entorno en el que los datos personales se procesan a gran escala y mediante sistemas complejos, prevenir estos fallos es, además de una obligación legal, una cuestión de ética, calidad y respeto hacia las personas. Asegurar que cada dato solo puede ser visto por quien tenga derecho a verlo es el mínimo exigible a cualquier entidad responsable.
La privacidad y la seguridad por defecto y desde el diseño y la responsabilidad proactiva no son formalidades: son la base de la confianza digital sobre la que debe construirse cualquier entidad moderna.
Pablo Fdez. Burgueño 