An insecure direct object reference vulnerability happens when an application requests a resource from the server (it can be a file, function, directory, or database record), by its name or other identifier, and allows the user to tamper directly with that identifier in order to request other resources.

Let's consider an example of this using Mutillidae II (navigate to OWASP Top 10 2013 | A4 - Insecure Direct Object References | Source Viewer). This exercise involves a source code viewer that picks a filename from the drop box and displays its contents in the viewer:

If you check the request in Burp Suite or any proxy, you can see that it has a phpfile parameter, which contains the name of the file to view:

You can try and intercept that request to change the filename to one that is not in the list, but you know that it exists on the server, such as passwords/accounts.txt (you can use the internet to search for default configuration files or relevant code installed on web servers and certain applications):

As the application references files directly by their names, you can change the parameter to make the application show a file that wasn't intended to be seen.