Referencias de objetos directos inseguras (IDOR, siglas en inglés) es a lo que conocemos como un tipo de vulnerabilidad de acceso de control. Estos IDOR son los tipos de vulnerabilidad que no se logran identificar con un simple escaneo de vulnerabilidad automatizado, sino que logra ser identificado mediante pruebas manuales. La razón por la que solo se identifica con pruebas manuales es por el simple hecho que son fallas de lógica del programa. Es decir, esto no es un error de código, sino que la manera que se realiza el proceso del programa no es el adecuado.
Un usuario que es propietario de su propia cuenta bancaria no debería poder consultar otras cuentas bancarias de otros usuarios. Esto es en si a lo que llamamos un IDOR. En el escenario de un atacante si identifica un IDOR, pudiera realizar transacciones de otros usuarios sin tener los privilegios de esos usuarios. En un ejemplo de cómo este atacante pudiera realizar otros tipos de transacciones a otros usuarios sería con el simple hecho que pudiera modificar la petición de la consulta en vez de utilizar el número de su cuenta bancaria utilizaría la de otro usuario para realizar una transacción.
Esta vulnerabilidad de falla de control de acceso es otra razón por la que debemos realizar auditoría a las aplicaciones web. Es importante entender que un escaneo de vulnerabilidad no lograría estas fallas ya que un escaneo no analiza la lógica del negocio, sino que analiza qué tipo de vulnerabilidades conocidas al momento puedan ser vulnerables a la infraestructura escaneada. Al final, un IDOR tiene una solución rápida, pero tiene un dolor de cabeza lograr identificarlos. Esto por lo que debemos tener un programa de inducción de la aplicación que se realiza la auditoria con el consultor de seguridad de la información para entender la lógica del negocio e identificar las fallas lógicas del control de acceso.