Wat is Insecure Direct Object Reference?
Insecure direct object reference (IDOR) is een toegangscontrolekwetsbaarheid waarmee aanvallers gegevens van andere gebruikers kunnen benaderen door objectidentificaties in applicatieverzoeken te manipuleren. Wanneer uw applicatie een databasesleutel, bestandsnaam of record-ID direct aan gebruikers toont en niet controleert of de aanvragende gebruiker eigenaar is van dat object, kan elke geauthenticeerde gebruiker de gegevens van een andere gebruiker bekijken of wijzigen door simpelweg een getal in een URL aan te passen.
IDOR is verantwoordelijk geweest voor enkele van de grootste datalekken ooit. In 2019 stelde First American Financial Corporation meer dan 800 miljoen afbeeldingen bloot met burgerservicenummers en bankrekeninggegevens, omdat de applicatie iedereen toestond een URL-parameter aan te passen om documenten van andere gebruikers te openen.
De kernfout is eenvoudig: de applicatie bevestigt dat een gebruiker is ingelogd (authenticatie), maar controleert nooit of deze gebruiker toegang mag hebben tot een specifiek record (autorisatie). Uw applicatie controleert het slot op de voordeur, maar laat iedereen binnen elk archiefkast openen.
IDOR komt overeen met CWE-639: Authorization Bypass Through User-Controlled Key. In de API-context wordt dezelfde kwetsbaarheid Broken Object Level Authorization genoemd, of BOLA, en staat op de eerste plaats in de OWASP API1 (API1:2023). De bovenliggende categorie, Broken Access Control, staat op #1 in de OWASP Top 10 en behoudt die positie in de 2025 editie.
Voordat we de werking bekijken, is het nuttig om de verschillende vormen van IDOR te begrijpen en waar het past binnen bestaande kwetsbaarheidsraamwerken.
Typen Insecure Direct Object Reference
IDOR is geen uniforme fout. Het manifesteert zich verschillend afhankelijk van de privilege-relatie en het type object dat wordt blootgesteld.
Horizontale IDOR
De meest voorkomende vorm. Een geauthenticeerde gebruiker benadert objecten die toebehoren aan een andere gebruiker met hetzelfde privilege-niveau, zoals het wijzigen van /api/users/123/profile naar /api/users/124/profile om de gegevens van een ander account te lezen. Er vindt geen privilege-escalatie plaats; de aanvaller overschrijdt simpelweg accountgrenzen binnen dezelfde laag.
Verticale IDOR
De aanvaller benadert objecten waarvoor hogere privileges vereist zijn dan hij bezit: toegang tot een admin-record, een beperkte configuratie-endpoint, of een beheerfunctie door een identificatie te manipuleren. Verticale IDOR leidt vaak tot volledige privilege-escalatie, zoals in het Honda eCommerce-geval waar een onderzoeker van dealer-niveau naar platformbeheerder ging.
API IDOR (BOLA)
In REST- en GraphQL-API's heeft hetzelfde probleem een andere naam: Broken Object Level Authorization (BOLA). Door het stateless karakter van API's is deze variant bijzonder wijdverspreid. Een enkele verkeerd geconfigureerde resolver of route handler kan elk record in een collectie blootstellen aan elke geauthenticeerde sessie.
Statische Resource IDOR
Bestandsdownloads, exports en rapportage-endpoints worden vaak overgeslagen tijdens autorisatiereviews. Als een applicatie een PDF serveert op /reports/invoice_1042.pdf zonder te controleren of de aanvragende gebruiker eigenaar is van die factuur, is de kwetsbaarheid structureel identiek aan een database-record IDOR. Deze variant komt veel voor in de zorg, financiële sector en juridische platforms waar documenten gereguleerde gegevens bevatten.
Elk van deze vormen correspondeert met een specifieke positie in gevestigde kwetsbaarheidsraamwerken, wat de classificatie van IDOR complex maakt.
OWASP-classificatie van Insecure Direct Object Reference
IDOR komt voor in drie afzonderlijke kwetsbaarheidsraamwerken, elk met een andere organisatorische kijk op dezelfde onderliggende fout.
| Framework | Entry | Naam | Huidige positie |
| OWASP Top 10 (2007–2013) | A4 | Insecure Direct Object References | Op zichzelf staand; niet langer als aparte entry |
| OWASP Top 10 (2021–2025) | A01 | Broken Access Control | #1 (dekt 40 CWEs, inclusief CWE-639) |
| OWASP API Security Top 10 | API1:2023 | Broken Object Level Authorization (BOLA) | #1 (Gemakkelijk te misbruiken, Wijdverspreid) |
| MITRE CWE | CWE-639 | Authorization Bypass Through User-Controlled Key | 2025 CWE Top 25 |
OWASP Top 10-plaatsing
IDOR was een aparte Top 10-entry van 2007 tot 2013. In 2017 werd het door OWASP samengevoegd onder Broken Access Control, dat in 2021 naar #1 steeg en die positie behoudt in de 2025-editie, nu met 40 CWEs onder deze categorie.
OWASP API Security Top 10
BOLA, de API-specifieke benadering van IDOR, staat sinds de introductie van de API Security Top 10 in 2019 op positie API1. De API1:2023-entry beoordeelt BOLA als het meest exploiteerbaar ("Gemakkelijk") en het meest voorkomend ("Wijdverspreid"), waardoor het consequent meer meldingen oplevert dan andere API-kwetsbaarheden.
CWE Mapping
CWE-639 (Authorization Bypass Through User-Controlled Key) is de primaire MITRE-classificatie voor IDOR. De bovenliggende categorie is CWE-284 (Improper Access Control). De meest specifieke subcategorie voor SQL-gebaseerde implementaties is CWE-566 (Authorization Bypass Through User-Controlled SQL Primary Key). CWE-639 staat in de 2025 CWE Top 25.
Het begrijpen van de taxonomie vormt de basis voor het onderzoeken van de daadwerkelijke exploitatie in de praktijk.
Hoe werkt Insecure Direct Object Reference?
IDOR maakt misbruik van een fundamentele kloof tussen wat uw applicatie authenticeert en wat het autoriseert. De onderstaande stappen laten zien hoe één blootgestelde identificatie kan leiden tot een grootschalig datalek.
Stap 1: De applicatie toont een directe objectreferentie
Uw applicatie genereert een URL of API-parameter die direct correspondeert met een intern object:
De waarde 123 is de primaire sleutel van een gebruikersrecord in de database, direct zichtbaar in het URL-pad.
Stap 2: De aanvaller wijzigt de identificatie
Een aanvaller verandert 123 in 124. Als de applicatie de profielgegevens van gebruiker 124 retourneert, is de kwetsbaarheid bevestigd.
Stap 3: De server haalt het object op zonder autorisatiecontrole
De OWASP-referentie toont een duidelijk kwetsbaar codepatroon
De @login_required-decorator bevestigt dat de gebruiker is ingelogd. Het controleert echter niet of gebruiker 123 toegang mag hebben tot het profiel van gebruiker 124. Het toevoegen van één regel lost de kwetsbaarheid op:
Stap 4: Exploitatie schaalt via enumeratie
Zodra een aanvaller het patroon bevestigt, schrijft hij een script om door mogelijke ID-waarden te itereren, waardoor één kwetsbaarheid uitgroeit tot een massaal datalek. Afhankelijk van de applicatie kan deze enumeratie snel worden uitgevoerd. De snelheid van exploitatie maakt van een enkele toegangscontrolefout een grootschalig datalek.
Vier primaire aanvalsvlakken
| Vlak | Voorbeeld |
| URL-padparameters | /invoices/1042 gewijzigd in /invoices/1043 |
| Querystring-parameters | ?order_id=7001 gewijzigd in ?order_id=7002 |
| Bestandsparameters | ?file=report_user1.pdf gewijzigd in ?file=report_user2.pdf |
| Verborgen velden in POST-body | user_id in een formulierinzending gewijzigd naar de ID van een andere gebruiker |
Deze aanvalsvlakken bestaan door diepere structurele oorzaken in de manier waarop applicaties zijn ontworpen en gebouwd.
Oorzaken van Insecure Direct Object Reference
IDOR ontstaat door structurele ontwerpbeslissingen en veelvoorkomende misvattingen bij ontwikkelaars die zich opstapelen binnen applicatiearchitecturen.
Ontbrekende autorisatie en ongescope queries
De primaire oorzaak is applicaties die door gebruikers aangeleverde input gebruiken om objecten op te halen zonder te controleren of de aanvragende gebruiker eigenaar is van het record. Dit komt het meest voor als ongescope databasequeries: applicaties die de volledige objecttabel bevragen (Order.find(order_id)) in plaats van de dataset van de geauthenticeerde gebruiker (current_user.orders.find(order_id)), waardoor alle records worden blootgesteld aan elke geauthenticeerde sessie.
Voorspelbare identificaties en directe sleutelblootstelling
MITRE CWE-639 benoemt dit expliciet: systemen die opeenvolgende of eenvoudig te raden record-ID's gebruiken, stellen aanvallers in staat gegevens van andere gebruikers te enumereren door waarden te verhogen. Het direct tonen van primaire databasesleutels in URL's of POST-bodies, vooral gehele getallen (1, 2, 3…), creëert een triviaal voorspelbaar aanvalsvlak.
De UUID-misvatting
Het OWASP-cheatsheet benoemt dit direct: complexe identificaties zoals GUIDs maken het raden van geldige waarden praktisch onmogelijk, maar toegangscontroles blijven essentieel. Als aanvallers geldige URL's verkrijgen via gedeelde links of applicatieresponsen, moet de applicatie nog steeds ongeautoriseerde toegang blokkeren.
Stateless API-architectuur
OWASP API1:2023 benoemt een structurele oorzaak specifiek voor API's: de server vertrouwt op parameters zoals object-ID's die door de client worden verzonden om te bepalen welke objecten worden benaderd. REST- en GraphQL-API's zijn structureel gevoelig voor IDOR zonder expliciete autorisatielogica per verzoek.
Wanneer deze oorzaken niet worden aangepakt, veroorzaken de resulterende kwetsbaarheden een bedrijfsimpact die verder reikt dan alleen de technische laag.
Impact en risico van Insecure Direct Object Reference
De impact van IDOR varieert van gegevensblootstelling tot volledige accountovername, met gevolgen op het gebied van regelgeving, financiën en veiligheid.
Gegevensblootstelling op schaal
Omdat IDOR-exploitatie te automatiseren is, kan één kwetsbaar endpoint een volledige database blootstellen. De IDOR van First American stelde 800 miljoen+ afbeeldingen bloot. Optus verloor klantgegevens via een vergeten API-endpoint met gebrekkige toegangscontrole.
Regelgevende en financiële sancties
IDOR-lekken leiden tot jarenlange handhaving door toezichthouders. First American kreeg sancties van de SEC en NYDFS. Ook Optus ondervond aanzienlijke financiële gevolgen.
Accountovername en privilege-escalatie
IDOR beperkt zich niet tot het lezen van gegevens. In een gedocumenteerd geval met Honda's eCommerce-platform kreeg een onderzoeker toegang tot alle dealerrecords door één ID-waarde te wijzigen en escaleerde vervolgens naar platformbeheerder, een rol voorbehouden aan Honda-medewerkers.
OWASP Ernstbeoordelingen
De OWASP API Top 10 beoordeelt BOLA als "Gemakkelijk" te misbruiken en "Wijdverspreid" voorkomend. De combinatie van eenvoudige exploitatie en brede verspreiding verklaart de #1-positie.
Deze ernstbeoordelingen weerspiegelen de methoden die aanvallers gebruiken om IDOR op schaal te misbruiken.
Hoe aanvallers Insecure Direct Object Reference misbruiken
IDOR-exploitatie volgt een gestructureerde workflow die minimale technische kennis vereist.
Parametervervanging
De aanvaller wijzigt een identificatie naar de waarde van een andere gebruiker en observeert de respons. Het wijzigen van /api/users/123/profile naar /api/users/124/profile en het ontvangen van een 200 OK-respons in plaats van 403 Forbidden bevestigt de kwetsbaarheid.
Geautomatiseerde enumeratie
Na bevestiging schalen aanvallers de exploitatie met Burp Suite's Intruder-module, OWASP ZAP of eigen scripts om alle mogelijke ID-waarden te doorlopen. De OWASP API-documentatie beschrijft hoe een eenvoudig script dat ID's in een URL manipuleert toegang geeft tot duizenden records.
Gekoppelde exploitatie
Aanvallers combineren IDOR met andere kwetsbaarheden. Het Honda eCommerce-geval toont horizontale gegevensbenadering gekoppeld aan verticale privilege-escalatie. Het McDonald's McHire-platform combineerde een IDOR met standaardwachtwoorden, wat de blootstelling vergrootte.
Horizontale en verticale toegang
De OWASP-toegangscontrolegids verduidelijkt het onderscheid. IDOR maakt meestal horizontale privilege-escalatie mogelijk: Gebruiker A benadert gegevens van gebruiker B op hetzelfde privilege-niveau. Minder vaak maakt IDOR verticale escalatie mogelijk: een standaardgebruiker krijgt beheerdersrechten.
De eenvoud van deze technieken betekent dat vrijwel elke applicatie die gebruikersgegevens verwerkt een doelwit kan worden.
Wie is getroffen door Insecure Direct Object Reference?
IDOR treft elke applicatie die door de gebruiker te controleren identificaties gebruikt om objecten te benaderen zonder autorisatiecontrole per verzoek.
Applicatiearchitecturen met hoog risico
Het IDOR-risico wordt vergroot door bepaalde structurele patronen die objectreferenties breder blootstellen of autorisatiecontroles makkelijker omzeilbaar maken.
- REST-API's met resource-gebaseerde URL-patronen. Elke API die
/resource/{id}-conventies volgt, heeft structurele IDOR-blootstelling. - GraphQL-API's. Argument-gebaseerde objecttoegang creëert dezelfde kwetsbaarheid wanneer resolvers eigendomcontroles overslaan.
- Multi-tenant SaaS-applicaties. Een gebruiker in één tenant manipuleert ID's om gegevens van een andere tenant te benaderen.
- IoT- en mobiele API-backends. Complexe authenticatiestromen en beperkte server-side statusverwerking vergroten BOLA-blootstelling.
- E-commerceplatforms. Order-ID's, factuur-ID's en klantaccountreferenties zijn waardevolle doelwitten.
Wat al deze architecturen gemeen hebben, is dat objecttoegang wordt aangestuurd door identificaties die de client beheert, waarbij de server geen eigendomcontrole uitvoert voordat gegevens worden teruggegeven.
Hoogrisicosectoren
De meest blootgestelde sectoren zijn die waar objectreferenties direct corresponderen met gevoelige records, gereguleerde gegevens of fysieke systemen.
- Zorg: CVE-2024-28320 (Hospital Management System, CVSS 7.6) maakte het mogelijk patiëntgegevens te lezen en te wijzigen.
- Financiële dienstverlening: Betaalplatforms en titelbedrijven lopen zowel gegevens- als regelgevingsrisico.
- Overheid: Volgens HackerOne melden overheidsprogramma's IDOR als een terugkerend probleem.
- Automotive: De Pandora/Viper-case en CVE-2025-11690 bevestigen reëel risico voor voertuigsysteem.
Gedocumenteerde lekken in deze sectoren illustreren de gevolgen van het niet aanpakken van IDOR.
Praktijkvoorbeelden van Insecure Direct Object Reference
De volgende gevallen tonen hoe IDOR zich manifesteerde in verschillende sectoren en applicatietypen. Elk incident is terug te voeren op dezelfde kernfout: door de gebruiker aangeleverde identificaties bereiken een server die nooit controleert of de aanvrager eigenaar is van het teruggegeven object.
First American Financial Corporation (2019)
De EaglePro-applicatie van First American stond elke gebruiker toe een URL-parameter te wijzigen en toegang te krijgen tot escrow- en titeldocumenten van andere gebruikers. De kwetsbaarheid, geïntroduceerd in 2014, bleef vijf jaar bestaan. Meer dan 800 miljoen afbeeldingen werden blootgesteld, waaronder burgerservicenummers en hypotheekbetalingsdocumenten. Regelgevende sancties zijn gedocumenteerd in de SEC-melding en NYDFS-melding. CISA, NSA en de Australian Signals Directorate verwezen naar dit geval in hun gezamenlijk IDOR-advies.
Optus Datalek (2022)
Een codeerfout uit 2018 brak de toegangscontrole op een Optus API-endpoint. Optus corrigeerde de fout op het hoofddomein in 2021, maar liet een vergeten, publiek toegankelijke domein ongepatcht. In september 2022 misbruikte een aanvaller de gebrekkige toegangscontrole om klantgegevens te exfiltreren, inclusief geldige persoonlijke ID-nummers. De Australische Communications and Media Authority (ACMA) bevestigde dat de aanval "niet zeer geavanceerd" was en werd uitgevoerd via "een eenvoudig proces van trial-and-error." Het blijft het grootste datalek van Australië.
McDonald's McHire Chatbot (2025)
Security-onderzoekers Ian Carroll en Sam Curry ontdekten een IDOR in de Paradox.ai McHire chatbot API die door McDonald's wordt gebruikt. Door een lead_id-integer in de interne /api/lead/cem-xhr-endpoint te verlagen, kregen ze volledige chattranscripten, contactgegevens en sessietokens van andere sollicitanten zonder autorisatiecontrole. Hun eigen lead_id was 64.185.742, wat de schaal van potentieel toegankelijke records aangeeft. De kwetsbaarheid werd op 30 juni 2025 gemeld en dezelfde dag verholpen.
Pandora en Viper Smart Car Alarms (2019)
Pen Test Partners vonden IDOR-kwetsbaarheden in smart car alarm API's waarmee volledige accountovername mogelijk was binnen wagenparken. Aanvallers konden accountwachtwoorden of e-mailadressen wijzigen en zo fysieke controle over voertuigen krijgen. De onderzoekers schatten dat ongeveer drie miljoen luxevoertuigen waren blootgesteld voordat leveranciers de fouten binnen enkele dagen na melding patchten.
Bug Bounty-signaal
IDOR is een consistent waardevolle vondst op bug bounty-platforms. Een PayPal-rapport leverde een aanzienlijke beloning op bij HackerOne, en HackerOne-data toont aan dat IDOR een terugkerende kwetsbaarheid blijft.
Deze incidenten illustreren meer dan tien jaar aanwezigheid van IDOR in grote kwetsbaarheidsraamwerken en praktijkgevallen.
Tijdlijn en geschiedenis van Insecure Direct Object Reference
IDOR maakt al bijna twee decennia deel uit van het formele beveiligingslandschap. De onderstaande tijdlijn volgt de ontwikkeling van een aparte categorie naar een fundamenteel concept in meerdere raamwerken, en de verdere uitbreiding naar nieuwe infrastructuren zoals API's, IoT en AI-systemen.
| Periode | Mijlpaal |
| 2007 | OWASP introduceerde de term "IDOR" in de Top Ten als aparte categorie op A4. |
| 2013-2014 | Laatste jaar als aparte OWASP-categorie (A4). IDOR-fout bij First American geïntroduceerd |
| 2017 | IDOR samengevoegd in Broken Access Control op A5. |
| 2019 | OWASP API Security Top 10 introduceerde BOLA als API1. First American-onthulling. Pandora/Viper-blootstelling gedocumenteerd. |
| 2021 | Broken Access Control op #1 in OWASP Top 10. |
| 2022 | Optus-lek, het grootste datalek van Australië. |
| 2023 | CISA/NSA/ACSC publiceerden gezamenlijk advies AA23-208A over IDOR. BOLA behouden op API1:2023. |
| 2025 | Broken Access Control blijft op #1, dekt 40 CWEs. CWE-639 opgenomen in de 2025 CWE Top 25. McDonald's McHire IDOR gemeld door Ian Carroll en Sam Curry. |
| 2024-2026 | IDOR breidt uit naar AI/LLM-infrastructuur (CVE-2025-4962), voertuig-telematica (CVE-2025-11690), en enterprise IAM (CVE-2024-56404). HackerOne bevestigt toename van IDOR-meldingen terwijl XSS en SQLi afnemen. |
Met de aanhoudende aanwezigheid van IDOR in bijna twee decennia kwetsbaarheidstracking, heeft u betrouwbare methoden nodig om het in uw eigen applicaties te vinden.
Hoe Insecure Direct Object Reference detecteren
IDOR is moeilijk te vinden met alleen tools, omdat het vereist dat men redeneert over eigendom van objecten en bedrijfslogica, niet alleen op basis van responsecodes.
Handmatige penetratietesten (vereist)
De OWASP WSTG beschrijft de testprocedure:
- Breng alle locaties in kaart waar gebruikersinput direct naar objecten verwijst.
- Wijzig de waarde van de parameter die wordt gebruikt om objecten te refereren.
- Beoordeel of u objecten van andere gebruikers kunt ophalen of autorisatie kunt omzeilen.
- Test verschillende HTTP-methoden en bulktoegangspatronen.
Handmatig testen is de enige methode die redeneert over autorisatie-intentie in plaats van alleen parametermanipulatie. Geen enkele scanner kan betrouwbaar een tester vervangen die begrijpt wat elke gebruikersrol wel en niet mag benaderen.
Application Security Testing Tools
DAST-tools zoals OWASP ZAP en Burp Suite kunnen IDOR vinden wanneer ze zijn geconfigureerd met multi-user testaccounts en cross-user object-ID-mapping. Standaard scannerconfiguraties zullen IDOR niet detecteren. SAST-tools kunnen endpoints markeren die autorisatiefuncties missen, maar kunnen niet bepalen of de autorisatielogica semantisch correct is tijdens runtime.
Gedragsmonitoring tijdens runtime
Dit is de enige productieregel die realistisch IDOR in productie kan vinden. Let op deze signalen:
- Opeenvolgende of enumeratiepatroon-verzoeken naar objectreferentie-endpoints vanuit één sessie
- Geauthenticeerde verzoeken die 200 OK retourneren voor object-ID's die niet bij de aanvragende gebruiker horen
- Groot aantal objectreferentie-verzoeken over meerdere gebruikersaccounts
In tegenstelling tot testen vóór implementatie werkt gedragsmonitoring continu in productie, waar daadwerkelijke exploitatie plaatsvindt. Het is de enige controle die IDOR kan detecteren terwijl het actief wordt misbruikt op live data.
Secure Code Review
Volgens het autorisatie-cheatsheet moet code review verifiëren dat toestemming bij elk verzoek wordt gevalideerd en toegangscontrole globaal is geïmplementeerd in plaats van per methode. Let vooral op endpoints die door de gebruiker aangeleverde identificaties accepteren en traceer het codepad van parameterinvoer via databasequery tot respons. Elk pad dat een object ophaalt zonder de query te beperken tot de toegangsrechten van de geauthenticeerde gebruiker vormt een bevestigd IDOR-risico.
Het vinden van IDOR is slechts de eerste stap. Preventie vereist controles die in uw volledige ontwikkel- en implementatiecyclus zijn ingebed.
Hoe Insecure Direct Object Reference voorkomen
Preventie vereist een gelaagde aanpak die ontwerp, ontwikkeling, testen en monitoring tijdens runtime omvat.
Ontwerpfase: Modelleer autorisatie in elke functionaliteit
Neem gebrekkige toegangscontrole op in uw aanvalsoppervlakte-analyse tijdens het ontwerpen van functionaliteiten. Definieer expliciete autorisatiefuncties (canAccess, isOwner-patronen) voordat u code schrijft.
Ontwikkelfase: Handhaaf server-side autorisatie bij elke objecttoegang
Het IDOR-cheatsheet specificeert deze controles:
- Implementeer toegangscontroles voor elk object dat een gebruiker probeert te benaderen. Bepaal de geauthenticeerde gebruiker op basis van sessie-informatie, niet op basis van door de client aangeleverde identificaties. Handhaaf controles via gecentraliseerde middleware in plaats van per methode.
- Beperk databasequeries tot de dataset die toegankelijk is voor de geauthenticeerde gebruiker:
Gebruik indirecte referentiemapping die verhulde externe waarden vertaalt naar interne database-ID's, gecombineerd met autorisatiecontroles.
Gebruik UUID's of lange willekeurige waarden als publiek zichtbare identificaties. Dit is een defense-in-depth-laag, geen primaire controle.
Vermijd identificatie-encryptie. Het OWASP-cheatsheet stelt dat dit "moeilijk veilig te implementeren is."
- Handhaaf autorisatie op statische resources, een vaak overgeslagen vlak volgens het autorisatie-cheatsheet.
Deze controles werken omdat ze eigendom afdwingen op het dataniveau in plaats van te vertrouwen op door de client aangeleverde waarden. Een aanvaller die een parameter manipuleert, stuit op een autorisatiecontrole in plaats van een geslaagde query.
Testfase: Multi-user autorisatietesten
Voer DAST-scans uit met multi-user configuraties die cross-account toegang testen. Neem SAST-regels op die endpoints markeren zonder autorisatiefuncties. Geef prioriteit aan handmatige penetratietesten voor business logic IDOR.
Runtime-fase: API-gedragsmonitoring
Implementeer gedragsmonitoring die normale API-toegangspatronen als baseline gebruikt en afwijkende objecttoegang signaleert. De Storyline-technologie van SentinelOne kan de volledige reeks API-interacties en identiteitscontext rond verdachte toegang reconstrueren, zodat uw team de forensische tijdlijn heeft om IDOR-exploitatie te bevestigen of uit te sluiten.
Het effectief implementeren van deze controles vereist de juiste combinatie van applicatiebeveiligingstools en monitoring tijdens runtime.
Tools voor detectie en preventie
Geen enkele tool dekt IDOR volledig. Effectieve dekking vereist een gelaagde combinatie van scanning tijdens ontwikkeling, monitoring tijdens runtime en handmatige validatie gedurende de gehele applicatielevenscyclus. De onderstaande tools dekken verschillende fasen, elk met eigen dekking en beperkingen.
Application Security Testing Tools
| Tooltype | Capaciteit | IDOR-dekking | Beperking |
| DAST (OWASP ZAP, Burp Suite) | Test draaiende applicaties via HTTP/S | Vindt IDOR met multi-user configuraties | Vereist handmatige opzet van cross-account tests |
| SAST (SonarQube, Checkmarx) | White-box broncode-analyse | Markeert ontbrekende autorisatie-aanroepen | Kan semantische juistheid van autorisatielogica niet verifiëren |
| IAST (Contrast Security) | In-app agent tijdens QA-testen | Gedragscontext tijdens runtime met minder false positives | Vereist geïnstrumenteerde testomgevingen |
| Handmatige pentest | Business logic, multi-user scenario's | Enige betrouwbare methode voor complexe IDOR | Tijdrovend, vereist ervaren testers |
API-beveiliging en gedragsmonitoring
Gedragsmonitoringtools voor API's bouwen baselines van normale toegangspatronen en signaleren afwijkingen. Dit zijn de enige runtime-controles die realistisch IDOR-exploitatie in productie kunnen detecteren, omdat IDOR-verzoeken syntactisch identiek zijn aan legitiem verkeer.
Gerelateerde kwetsbaarheden
IDOR behoort tot de bredere Broken Access Control-familie. Inzicht in de relatie met gerelateerde kwetsbaarheidstypen helpt bij het prioriteren van herstelmaatregelen.
- Broken Object Level Authorization (BOLA), API1:2023. Zowel IDOR als BOLA corresponderen met CWE-639. BOLA is de API-specifieke benadering van dezelfde onderliggende fout.
- Broken Function Level Authorization (BFLA), API5:2023 / CWE-285. Waar IDOR zich richt op data-objecten (welke records u kunt benaderen), richt BFLA zich op API-functies (welke bewerkingen u kunt uitvoeren), vooral voor verticale privilege-escalatie.
- Forced Browsing (CWE-425). Omzeilt navigatie- en paginacontroles om direct toegang te krijgen tot beperkte pagina's, genoemd als concreet Broken Access Control-voorbeeld.
- SQL Primary Key Authorization Bypass (CWE-566). Een directe subcategorie van CWE-639, dit is de meest specifieke CWE voor SQL-gebaseerde IDOR-implementaties.
- Vertical Privilege Escalation (CWE-269 / CWE-285). IDOR kan leiden tot privilege-escalatie wanneer een aanvaller een identificatie wijzigt om administratieve functies te benaderen, zoals aangetoond in het Honda eCommerce-geval.
Verschillende specifieke CVE's tonen aan hoe deze gerelateerde kwetsbaarheidspatronen voorkomen in productiesystemen.
Gerelateerde CVE's
| CVE-ID | Beschrijving | Ernst | Getroffen product | Jaar |
| CWE-639 IDOR in Tableau Server tab-doc API-modules; aanvaller op het aangrenzende netwerk manipuleert door de gebruiker beheerde sleutels om autorisatie te omzeilen en toegang te krijgen tot productie-databaseclusters | HOOG | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| CWE-639 IDOR in Tableau Server set-initial-sql tabdoc-commando; geauthenticeerde gebruikers met lage privileges manipuleren door de gebruiker beheerde parameters om toegang te krijgen tot productie-databaseclusters | HOOG | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| CWE-639 IDOR in Chainlit thread resource handling; geauthenticeerde gebruikers leveren de thread-ID van een andere gebruiker aan om gespreksgegevens te benaderen zonder eigendomscontrole | MEDIUM | Chainlit | 2025 | |
| CWE-639 IDOR in Five Star Restaurant Reservations WordPress-plugin; niet-geauthenticeerde aanvallers manipuleren reserveringsidentificaties om records van andere gebruikers te benaderen, wijzigen of verwijderen | MEDIUM | Five Star Restaurant Reservations WP plugin (≤2.7.8) | 2025 | |
| IDOR in One Identity Identity Manager maakt privilege-escalatie mogelijk in on-premise installaties; aanvaller manipuleert objectreferenties om rechten te verkrijgen buiten de toegewezen rol | CRITISCH | One Identity Identity Manager 9.x (<9.3) | 2024 | |
| Niet-geauthenticeerde IDOR in SO Planning tool; wanneer publieke weergave is ingeschakeld, kan een aanvaller de volledige onderliggende database benaderen door het export-endpoint direct aan te roepen en deze als CSV te downloaden | CRITISCH | SO Planning (<1.52.02) | 2024 | |
| Niet-geauthenticeerde IDOR in WooCommerce Stripe Payment Gateway; ontbrekende order-eigendomscontrole stelt naam, e-mail en adres van elke bestelling bloot aan niet-geauthenticeerde gebruikers bij meer dan 900.000 actieve installaties | HOOG | WooCommerce Stripe Payment Gateway WP plugin (≤7.4.0) | 2023 | |
| CWE-639 IDOR in ExtremePacs Extreme XDS medisch beeldvormingsplatform; manipulatie van door de gebruiker beheerde sleutels maakt toegang mogelijk tot beeldrecords van andere patiënten zonder autorisatie | HOOG | ExtremePacs Extreme XDS (<3914) | 2023 | |
| IDOR in gedeelde stalkerware backend-server stelde sms-berichten, belgeschiedenis, foto's en locatiegegevens van honderdduizenden apparaten bloot; genoemd in CISA/NSA/ACSC Advisory AA23-208A | HOOG | 1byte / Meerdere stalkerware-apps | 2022 | |
| IDOR in wachtwoordresetfunctie van Telos Alliance Omnia MPX Node; aanvaller levert het account-ID van een willekeurige gebruiker aan om diens wachtwoord te resetten, waardoor volledige accountovername mogelijk is, inclusief Administrator-accounts | HOOG | Telos Alliance Omnia MPX Node (1.0.0–1.4.x) | 2022 |
Ontketen AI-aangedreven cyberbeveiliging
Verhoog uw beveiliging met realtime detectie, reactiesnelheid en volledig overzicht van uw gehele digitale omgeving.
Vraag een demo aanConclusie
Insecure direct object reference blijft een van de meest misbruikte webbeveiligingsfouten omdat het objectniveau-autorisatie doorbreekt, niet alleen inputafhandeling. Als uw applicatie vertrouwt op door de gebruiker aangeleverde identificaties zonder eigendom te controleren, kan een kleine wijziging in een URL leiden tot grootschalige gegevensblootstelling.
U verkleint dat risico door autorisatie bij elke objecttoegang af te dwingen, te testen in meerdere gebruikerscontexten en misbruik in productie te monitoren.
Veelgestelde vragen
IDOR is een gebrek aan handhaving van eigendom van records. Als uw server niet verifieert of een gebruiker toegang mag hebben tot een specifiek object, kan het wijzigen van een bestandsnaam, ordernummer of profiel-ID gegevens van iemand anders blootstellen of wijzigen. In de praktijk is IDOR in de eerste plaats een autorisatieprobleem en in de tweede plaats een parameter-manipulatieprobleem.
Ja. Oudere OWASP-documentatie noemt het mogelijk IDOR, terwijl nieuwere richtlijnen het onder Broken Access Control plaatsen. Teams die zich op API's richten noemen hetzelfde probleem vaak BOLA.
Verschillende labels wijzen op dezelfde onderliggende oorzaak: ontbrekende object-niveau autorisatie.
Ja. Een aanvaller heeft meestal alleen een bereikbaar eindpunt en een geldige manier om verzoeken te versturen nodig. Meestal is geen code-uitvoering of malwarelevering vereist.
Zodra één objectreferentiepatroon werkt, kan misbruik zich uitbreiden via gescripte verzoeken. Daarom zijn vergeten domeinen, oude API-versies en blootgestelde mobiele backends extra risicovol.
Applicaties zijn het meest kwetsbaar wanneer objectopzoeking wordt aangestuurd door clientinvoer. Het risico neemt toe in systemen die veel objectreferenties blootstellen, infrastructuur delen tussen tenants of afhankelijk zijn van stateless API's die herhaaldelijk vertrouwen op door de client verzonden ID's. Kritieke handelingen zijn onder andere het ophalen, bijwerken, exporteren of verwijderen van aan gebruikers gekoppelde records.
Aanvallers beginnen meestal waar de applicatie laat zien hoe objecten worden benoemd: een zichtbaar ID in een URL, verborgen formulierveld, JSON-body of API-respons. Vervolgens wisselen ze waarden uit, vergelijken ze reacties en testen ze verschillende methoden of accountcontexten.
Zelfs kleine verschillen in statuscodes, responsgroottes of geretourneerde velden kunnen bevestigen dat objecttoegang te misbruiken is.
De eerste signalen zijn meestal gedragsmatig. Let op één geauthenticeerde identiteit die veel object-ID's opvraagt, account- of tenantgrenzen overschrijdt of records benadert in een volgorde die niet overeenkomt met normaal gebruikersgedrag.
Omdat IDOR vaak verborgen zit in verder geldige HTTP-verkeer, is context belangrijker dan syntax.
De ernst komt voort uit schaal en betrouwbaarheid, net zo goed als uit ruwe CVSS. Veel kwetsbaarheden vereisen fragiele exploitketens; IDOR werkt vaak met normaal applicatiegedrag zodra de eigendomscontrole ontbreekt.
Het kan variëren van beperkte datalekken tot accountovernames of privilege-escalatie, afhankelijk van het blootgestelde object.
Soms. Als het blootgestelde object wachtwoordresets, beheerdersinstellingen, tenantgrenzen of workflowacties beheert, kan IDOR de eerste stap zijn in een grotere overname.
De bedrijfsfunctie van het object bepaalt of de kwetsbaarheid lokaal blijft bij één record of uitgroeit tot een platformbreed incident.
Niet standaard. Tools kunnen invoer vinden en verzoeken herhalen, maar IDOR vereist inzicht in wie welk object zou moeten bezitten en hoe rollen verschillen tussen sessies.
De meest effectieve aanpak combineert automatisering met voorbereide multi-user testdata en handmatige validatie. In productie is gedragsmonitoring realistischer dan alleen vertrouwen op scanners.
De sectoren met het hoogste risico zijn die waar objectreferenties direct gekoppeld zijn aan gevoelige records, gereguleerde gegevens of fysieke gevolgen. In de praktijk omvat dit medische dossiers, financiële documenten, overheidsgegevens, autosystemen en identity-management assets.
In deze omgevingen kan elke ongeautoriseerde objecttoegang grote gevolgen hebben voor privacy, compliance, fraude of veiligheid.
