Insecure Direct Object Reference, more generally known as “IDOR”, is a permission based flaw which enables an attacker or a hacker to access or modify resources that belong to other users of the web application, or rather resources which are not permitted to be controlled by the attacker.
The primary key behind Insecure Direct Object Reference is that a part of a web application attempts to display or modify some resource such as a message, image, or file using a user-supplied (or user-controlled) identifier in the request, but doesn’t check whether the user has sufficient permission to perform the task.
XSS (cross site scripting) and CSRF (cross-site request forgery) vulnerabilities are difficult to discover nowadays because web development frameworks such as Rails or Django have built-in filters for XSS and token mechanisms for CSRF, whereas IDOR is a permission-relevant problem and cannot be fixed automatically or by default as permission use-cases change from the web application to web application. So this type of vulnerability is everywhere, in fact, it is so common that the majority of the publicly-disclosed Facebook security bugs are Insecure Direct Object References.
Preventing insecure direct object references flaws requires selecting an approach for protecting each user accessible object (such as object number, filename): Use per user or session indirect object references. This will prevent hackers from directly targeting unauthorized resources.
