The correct answer to this question is D, Insecure Direct Object References. These references happen when an application gives direct access to objects. The access is based on an input supplied by a user. This makes attackers get through authorization and access resources in the system.

The resources could be records or files. It can also include the modification values of parameters. There are ways to test the vulnerability, including mapping out locations where the user input was used. Insecure Direct Object References can come in many forms, including attack mechanics, where the URLs are manipulated through a request. They can manipulate the URL and parameter.

The correct answer to this question is D. When an application offers direct access to objects due to input provided by the user, this is called an Insecure Direct Object Reference. If a user's authorization is not validated, an attacker can access the system and directly access resources such as files, directories, or database records, making the system vulnerable to being hacked and important data stolen.

Unfortunately, according to the Open Web Application Security Project (OWASP), it is more commonplace than many people would think that an insecure direct object references vulnerability, making this vulnerability easy to exploit in many systems.