Glosario
Qué es IDOR: ver los datos de otra persona con solo cambiar un ID
IDOR (Insecure Direct Object Reference / control de acceso roto) permite cambiar un ID en una URL o un parámetro y alcanzar datos que no son tuyos. Cómo funciona y la defensa real (comprobar en cada solicitud, en el servidor, si ESTE usuario puede acceder a ESTE objeto), en clave defensiva, sin pasos de ataque.
"Cambié id=124 por 125 en la URL y apareció la factura de otra persona": eso es IDOR (control de acceso roto). 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 pasa sin problema |
| Error de "no se muestra en la interfaz = seguro" | Llamar a la API directamente queda totalmente abierto |
| Sin comprobación de permiso en crear/actualizar/borrar | No solo visualizar: también manipular y borrar |
Por qué funciona
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.
La opinión de este sitio: poco vistoso, pero de máximo impacto — protégelo con pruebas
IDOR es técnicamente soso y fácil de pasar por alto en una revisión de código, pero el impacto es de primer nivel ("un clic revela los datos personales de todo el mundo"). Por eso el gesto práctico es fijar una prueba automatizada: como otro usuario, acceder al 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.
Sigue leyendo
- Glosario: Qué es CSRF (autenticación vs autorización)
- Fundamentos: Fundamentos de seguridad · Herramientas de seguridad gratuitas
FAQ
Q¿Qué ocurre con IDOR?
Un usuario con sesión iniciada cambia un ID en una URL o una API (?id=124 por otro valor) y visualiza, edita o borra la factura, el pedido, los datos personales o los archivos de otra persona. Es el buque insignia de la clase de fallos más común (control de acceso roto) y da miedo porque no necesita herramientas especiales.
Q¿Cuál es la principal defensa?
En cada solicitud, en el servidor, verifica '¿puede ESTE usuario con sesión iniciada actuar sobre ESTE objeto?'. Aunque el ID esté bien formado, comprueba la propiedad/permiso y deniega si falta (denegar por defecto). Nunca confíes en ocultar elementos de la interfaz en el cliente.
Q¿Los UUID o los IDs aleatorios lo evitan?
Solo hacen los IDs más difíciles de adivinar; no son un arreglo real. Si un ID se filtra o se comparte, pasa sin problema. Mantén la aleatorización como ayuda; la defensa real es siempre una comprobación de propiedad/permiso en el servidor.