Skip to content

Month: March 2020

On Insecure Direct Object References (IDOR)

[Work in Progress]

Questions to take note about the application:

How does the application identify the user?
We want to know how the user is being identified by the application server. Such information may be found in cookies, request url, etc. Example of information to take note includes user_id, id, account_id, etc. There might also be cases where the user is identified only by session id. Sometimes the information is encoded and store as tokens. Sometimes developers might try to fool the users by encrypting their usernames and then use it as an identifier.

What are the data objects can be retrieved and the actions that the user can perform?
We need to know what are the data that are being retrieved by the users and observe the method that is used. Also we want to see what kind of actions can be performed by the different user roles so that we test if the privileges can be escalated.

Where can I find IDORs?

  • Look at API documents of the applications and see if any id is used.
  • Look at applications that process many documents such as images, files, etc that can be retrieved by the user in the future.


  • OWASP Juice Shop – View another user’s shopping basket.

Useful Resources:

Disclosure Reports

Using Postman to automate some Security Test Cases

There are many available testing tools that help Security and Software engineers to automate their security testing. However, there are situations which requires some manual testing in order to discover vulnerabilities. Still, we don’t have to manual test the same test cases every time. After we discover the test workflow, we can write a test case in Postman and run it automatically in our CI/CD platform.

In this article, I will demonstrate some ways to automate the manually generated test cases using Postman. One of the ways is to capture the traffic when we are testing manually and then export it into Postman. Then we can write a test case in JavaScript to validate the response based on the type of vulnerabilities. Some improvement can be made is to include different payloads in the test cases.

Capturing Traffic of the workflow

In this example, I will be using Burp suite (Community Edition) to demonstrate how we can capture the workflow and export it to Postman.

First, install the Postman Integration extension to Burp suite. This allows us to export the request to Postman.

Install Postman Integration in BApp Store

Now, we will be using to capture a XSS payload request.

Enter the XSS payload in the search bar
An alert box displaying 1 should appear. This shows that the search bar is vulnerable to XSS.

We can observe that the payload ‘<script>alert(‘1′)</script>’ appears in the response. Later on, we want to use this observation to write a test case that will fail the XSS test if ‘<script>alert(‘1′)</script>’ appears in the response.

Now we want to export this request to Postman. Simply right click on the request and click ‘Export as Postman Collection’.

There will be a pop-out that allows us to set the Collection Name and Folder Name. We can also name the Test case (in this case, I named it as ‘Test XSS in Search Bar’). After the values are set, we can export it and then import the file into Postman.

Open up Postman and click ‘Import’. Choose the exported file and import to Postman. The Collection will appear at the side menu and we will see a folder called XSS. The request will be found in the folder.

Run the test and we shall see that the payload is in the response.

Writing Test case in Postman to validate

We can write the test case in JavaScript. For more information, please visit this link.

Since we know that this web application does not use any JS Frameworks (like Angular / ReactJS), we can simply check if the response will return the exact payload to validate if it contains a reflected XSS vulnerability.

In Postman, click on the ‘Tests’ tab. We can write a test case to test for reflected XSS. So if the response does not include the payload ‘<script>alert(‘1′)</script>’, then it passes the reflected XSS. And we can include different payload as well to ensure that the web application defence against XSS is robust.

In this scenario, we can see that the test failed because reflected XSS is found.