A4 – Preventing Insecure Direct Object References
When an application allows an attacker, who is an authenticated user, to simply change a parameter value that directly refers to a system object in a request and with that gain access to another object that isn't authorized, then we have an Insecure Direct Object Reference (IDOR). A couple of examples that we have already seen are the Local File Inclusion and Directory Traversal vulnerabilities.
According to OWASP, IDOR is the fourth most critical type of vulnerability in Web applications. These vulnerabilities are usually caused by a deficient access control implementation or the use of a "Security through obscurity" policy—if the user cannot see it, they will not know it exists—which tends to be a very common practice among inexperienced developers.
In this recipe, we will cover the key aspects that should be taken into account when designing access control mechanisms in order to prevent IDOR vulnerabilities.
How to do it...
The use of indirect...
