IDOR staat voor Insecure Direct Object Reference. Het is een kwetsbaarheid in de toegangscontrole van een webapplicatie of API. Een applicatie gebruikt een verwijzing die de gebruiker zelf meestuurt, bijvoorbeeld een ID in de URL, om een object op te halen. Bij een IDOR controleert de applicatie vervolgens niet of die gebruiker dat object ook mag inzien.
Stel, u bekijkt uw factuur op https://voorbeeld.nl/factuur?id=1042. Verandert u dat nummer in 1043 en krijgt u de factuur van een andere klant te zien, dan is er sprake van een IDOR. De applicatie vertrouwt blind op het meegestuurde ID en vergeet te controleren van wie die factuur eigenlijk is.
Het verraderlijke aan IDOR is dat er geen speciale tools voor nodig zijn. Een aanvaller past een waarde aan en kijkt wat er gebeurt. Juist daarom komt het vaak voor en kan het in één keer veel gevoelige gegevens lekken. In de context van API’s heet dezelfde fout Broken Object Level Authorization (BOLA), en die staat al jaren bovenaan de OWASP API Security Top 10.
Een IDOR los je niet op door de ID’s onvoorspelbaar te maken. Een willekeurig nummer maakt misbruik lastiger, maar het echte probleem blijft bestaan: de applicatie hoort bij elk verzoek opnieuw te controleren of de ingelogde gebruiker recht heeft op het opgevraagde object. Die controle hoort aan de serverkant plaats te vinden, niet in de browser.
Tijdens een pentest testen onze pentesters dit gericht. Ze proberen met het ene account bij de gegevens van een ander account te komen, en kijken of de applicatie dat tegenhoudt.