Insecure Direct Object References seems a pretty unwieldy term, but the way it compromises a web application is pretty straightforward. The attacker is usually an authorized system user, who simply modifies a parameter value that directly refers to a system object so it refers to another system object for which the attacker has no authorization. Potentially, an attack using this technique can compromise all data that the new parameter can reference.
The root of this type of web application vulnerability lies in the fact that that applications are not always set up to verify if a user is authorized to access the target object. Fortunately, a thorough code review can reveal if your applications suffer from this vulnerability. Testers can also manipulate parameter values to look for this vulnerability. The testers need to confirm that a user is authorized to access only the exact restricted resource they have requested. If the user is making indirect reference to an object, the application developer must limit the mapping to the direct resource to only the authorized values for that user.
Automated web application vulnerability tools don’t do a good job of finding this type of security flaws because the tool has no idea as to which objects are sensitive and need to be protected. Developers can sue reference maps (available from OWASP) to prevent direct access to unauthorized references. In addition, developers can code checks for each use of direct object reference from an untrusted source to ensure that the user is indeed authorized to access the indirect object. The goal is to prevent a hacker from being able to manipulate parameter settings in their browsers to send requests to the database for which they have not been authorized.