Insecure Direct Object Reference (IDOR)

If a reference to an internal implementation object, such as a file or database key, is exposed to a user without any other access control check, an attacker could manipulate these references and get access to unauthorized data.

What can happen?

It is impossible to say what the potential impact of IDOR is, as it varies a lot depending on what kind of data or file the attacker may get hold of. It could be anything from innocent information to bank statements or even more sensitive data.

Due to IDOR being so easy for an attacker to exploit, this is a vulnerability that is very likely to be abused. While this is often the case, it sometimes varies as it may not always be obvious how to enumerate the links for the files.

Example of Insecure Direct Object References

When logging in to online banking, the user is redirected to:

123 is the ID of the user’s account and the account that the user will see the balance for. By just changing that number, we will see the balance of someone else instead.


Have a check in place to ensure the user is only allowed to access the requested information.