IDOR (control de acceso roto) es cuando cambiar id=124 por 125 en una URL muestra la factura de otra persona. Aquí tienes cómo funciona y cómo prevenirlo de forma fiable (sin pasos de ataque).
Por qué ocurre
La autenticación (quién eres) pasa, pero la autorización (¿puedes hacer esto?) falta. La autenticación y la autorización son distintas: poder iniciar sesión no significa tener permiso para ver esos datos.
| Hueco común | Resultado |
|---|---|
| Confiar en el ID tal cual tras el inicio de sesión | Cámbialo por el ID de otro usuario y el acceso funciona |
| Error de "no se muestra en la interfaz = seguro" | Llamar a la API directamente no está bloqueado |
| Sin comprobación de permiso en crear/actualizar/borrar | No solo visualizar: también manipular y borrar |
Por qué funciona
Los IDs no solo aparecen como ?id= en una URL. Las rutas de API (/api/orders/125), los cuerpos JSON ("userId": 125), las URLs de descarga de archivos y los campos ocultos de formularios necesitan la misma comprobación: en cualquier sitio donde un valor enviado por el usuario elija sobre qué objeto actuar.
Términos relacionados
IDOR es una forma de control de acceso roto. Recibe varios nombres y es fácil confundirlo con sus vecinos.
| Término | Qué falta | Ejemplo |
|---|---|---|
| IDOR | Comprobación de propiedad/permiso por objeto | El usuario A cambia un ID y ve la factura del usuario B |
| BOLA | Lo mismo que IDOR (nombre de OWASP API Security) | /orders/{id} en una API devuelve el pedido de otra persona |
| Fallo de autorización a nivel de función | Comprobación de permiso por función | Un usuario normal puede llamar a una API solo para administradores |
| Autenticación rota | La propia comprobación de «quién eres» | Se puede llamar a la API sin iniciar sesión |
En el OWASP Top 10, Broken Access Control (A01) ocupa el primer puesto en la edición de 2025, igual que en 2021. En el OWASP API Security Top 10 (2023), centrado en APIs, BOLA también es el primero (API1:2023).
Casos reales: datos ajenos visibles tras iniciar sesión
Dos casos del sector público que este sitio ha cubierto se atribuyeron oficialmente a defectos introducidos durante actualizaciones del sistema, pero el resultado tuvo la misma forma que un fallo de autorización: un usuario con sesión iniciada podía llegar a datos que no eran suyos.
- Companies House del Reino Unido (marzo de 2026): los usuarios con sesión iniciada en WebFiling podían, mediante ciertas acciones, llegar a ver los domicilios particulares de administradores de otras empresas y otros datos, y técnicamente era posible presentar documentos sin autorización. El organismo afirma que fue un defecto introducido en una actualización del sistema de octubre de 2025, no un ataque externo → análisis completo (en inglés)
- e-Tax de la Agencia Tributaria Nacional de Japón (septiembre de 2026): un defecto de una actualización de Mi Página permitió a otros usuarios ver las declaraciones del impuesto sobre donaciones y documentos relacionados de 79 personas → análisis completo (en inglés)
En ambos, la comprobación de inicio de sesión funcionaba. Lo que faltaba era «¿puede este usuario actuar sobre este objeto?». Y los dos ocurrieron tras un cambio. Incluso una versión correcta puede perder la comprobación al añadir una función, por eso compensa tener una prueba automatizada que se ejecute siempre.
Defensa: verifica la propiedad/permiso en el servidor, cada vez
Comprueba la propiedad/permiso por objeto (lo más importante)
Justo antes de devolver o modificar datos, verifica en el servidor que el usuario con sesión iniciada posee ese objeto o tiene permiso sobre él. Deniega si no.
Deniega por defecto
Los nuevos endpoints parten de "denegar todo salvo lo permitido explícitamente", de modo que una comprobación olvidada falla cerrada, no abierta.
Consulta solo 'tus propias' filas
Incorpora la condición de propietario en la propia consulta (p. ej. filtrar por el id del usuario actual). Encamina todo a través de un único ayudante de autorización compartido para que ningún punto de llamada lo olvide.
No confundas el control de la interfaz con la defensa
Ocultar un botón es UX, no seguridad. Asume que la API se llama directamente y decide solo en el servidor. Mantén los IDs aleatorios como ayuda, no como el control.
Cómo revisar tu propia aplicación
Hazlo solo en una aplicación que desarrolles o administres. Probarlo en el servicio de otra persona puede ser un acceso no autorizado.
- Crea los usuarios de prueba A y B y dale a cada uno un registro (un pedido, un archivo, etc.)
- Con la sesión de A, llama a las APIs de ver, actualizar y borrar con un ID que apunte al registro de B. Llama a la API directamente desde las herramientas de desarrollo o un cliente de API, no a través de la interfaz
- Confirma que todas las solicitudes se rechazan con 403 o 404. Comprueba también que los listados no incluyen registros de B
- Conviértelo en una prueba automatizada y añade la misma prueba cada vez que añadas un endpoint
El OWASP API Security Top 10 también recomienda escribir pruebas que evalúen el mecanismo de autorización y no desplegar cambios que hagan fallar esas pruebas.
La opinión de este sitio: fácil de pasar por alto pero de gran impacto, así que compruébalo con pruebas automatizadas
IDOR es técnicamente soso y fácil de pasar por alto en una revisión de código, pero el impacto es grave ("un clic revela los datos personales de todo el mundo"). Por eso el gesto práctico es añadir una prueba automatizada: como otro usuario, solicitar el ID de otro debe devolver 403. El principio de este sitio es "nunca defender en la interfaz del cliente; decidir solo en el servidor". La autorización debe imponerla un mecanismo en cada solicitud, nunca dejarse a la atención humana.
Fuentes (primarias)
- OWASP Top 10:2025, «A01 Broken Access Control» — top10.owasp.org (en inglés; posición en el ranking y ejemplo de referencias directas inseguras a objetos)
- OWASP API Security Top 10 2023, «API1:2023 Broken Object Level Authorization» — api-security.owasp.org (en inglés; prevención y recomendación de pruebas)
- MITRE CWE-639: Authorization Bypass Through User-Controlled Key — cwe.mitre.org (en inglés)
- Las fuentes de los dos casos (comunicados de Companies House y de la Agencia Tributaria Nacional) figuran en cada análisis
Sigue leyendo
- Aprende: Autenticación frente a autorización (iniciar sesión ≠ autorización; IDOR es una forma de esa autorización ausente)
- Casos: Fallo de WebFiling de Companies House · Declaraciones del impuesto sobre donaciones visibles para otros usuarios en e-Tax (en inglés)
- Glosario: Qué es CSRF (ataque que abusa de tu sesión iniciada) · Qué es el OWASP Top 10 · Qué es la fijación de sesión
- Fundamentos: Fundamentos de seguridad · Herramientas de seguridad gratuitas