Insecure Direct Object References- A Security Hole

A “strange” security hole with a long, and difficult-to-read name.

Photo by Markus Spiske on Unsplash

What is strange?

This security hole is “strange” in that it is in the top 4 OWASP, but there is very little documentation about it. It is not known as XSS or CSRF or SQL Injection (Although its OWASP rank is much higher than XSS or CSRF).

I myself have never heard of the press or news mentioning this error before. Is it possible that there are no well-known cases related to it, or is it because the bug has many complex variations?

The main cause of this vulnerability is the carelessness of a developer or sysadmin (If you encounter this error, you have to drag the developer to cut first, then cut the tester).

This vulnerability occurs when the program allows users to illegally access resources (data, files, folders, database) through the user's data.

Photo by Moon Bhuyan on Unsplash

How to take advantage of the vulnerability

Very casually, I discovered this error while helping a younger brother test the sales web project.

In the “Manage Orders” section, the URL of an order will look like this: The server will read ID 1230 from the URL, then find the order with ID 1230 in the database and dump the data into HTML.

Imitating the hacker, I “playfully” a bit, replacing 1230 with the values ​​from 1 to 2000. The system just read and displayed all orders with IDs from 1 to 2000 (including orders of other customers). Harmful yet!

The flaw is: the program allows me to access illegal resources (other people’s orders), through data (ID) that I provide through the URL. The program should have checked to see if it had access to these data.

Hackers can use many tricks such as changing URLs, changing API parameters, and using tools to scan unsecured resources. My old hack lotte cinema is similar, replacing the URL with the username in the cookie.

There are a few rare cases; hackers can scan the git repository located on the server. Git access, he gets the username, password of the database and other important information.

How to take advantage of the vulnerability


Photo by Paweł Czerwiński on Unsplash

Some preventive measures:

Test carefully — The cause of the error is often the carelessness of the developer. However, if the product fails, this is the tester’s fault. This is an error in the code, so the tester is responsible for letting this error happen to the user.
Data protection “jump sensitive” — ​​For “sensitive” data such as source code, config, database key, it is necessary to limit access. The best way is to allow the internal IPs to access this data, hackers away from the computer.
Most important: Strictly check user permissions
Avoid exposing the object’s key — In the above cases, the object’s id is an int so that the hacker can guess other objects' id. To prevent this, we can encrypt id, using GUID as id. Hackers cannot detect the ID of another object.

Some additional sources for reference:



Always be nice to anybody who has access to my toothbrush.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store