One vulnerability that we have seen a bit of lately (and is sure to lure all the web attackers to your site) is the infamous insecure direct object reference.
When a web application makes a request to specific data, usually data owned by the current user, it has to use some sort of unique identifier in order for the application and database to be able to return the correct data.
Sometimes the URL looks something like this:
The value after the “id” parameter is the unique identifier. When the application gets that request, in theory it will return the correct data.
What happens if we change the value of “34” to “35”. Will it return another user’s data? If so, there is a direct object reference vulnerability. It is very easy to test for. Sometimes you can just change the value in the browser address bar, sometimes you need to use a web proxy such as Burp Suite (a free version is available).
In the code there should be a check that ensures that the data being requested does, in fact, belong to the current user. Direct object references are easy to exploit, and very easy to write a quick script to cycle through all potential values, store the results and use the returned data for nefarious purposes. Make sure you implement a check for this finding in your QA process.