Wat is Insecure Direct Object Reference?
Insecure direct object reference (IDOR) is een toegangscontrolekwetsbaarheid waarmee aanvallers toegang krijgen tot gegevens van andere gebruikers door objectidentificaties in applicatieverzoeken te manipuleren. Wanneer uw applicatie een databasesleutel, bestandsnaam of record-ID direct aan gebruikers toont en niet controleert of de verzoekende gebruiker eigenaar is van dat object, kan elke geauthenticeerde gebruiker eenvoudig door het wijzigen van een getal in een URL de gegevens van een andere gebruiker bekijken of aanpassen.
IDOR is verantwoordelijk geweest voor enkele van de grootste datalekken ooit. In 2019 stelde First American Financial Corporation meer dan 800 miljoen afbeeldingen met burgerservicenummers en bankrekeninggegevens bloot omdat de applicatie iedereen toestond een URL-parameter te wijzigen 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.
.jpg)
Typen Insecure Direct Object Reference
IDOR is geen uniforme fout. Het manifesteert zich verschillend afhankelijk van de betrokken privilegeverhouding en het type object dat wordt blootgesteld.
Horizontale IDOR
De meest voorkomende vorm. Een geauthenticeerde gebruiker krijgt toegang tot objecten van een andere gebruiker op hetzelfde privilegeniveau, bijvoorbeeld door /api/users/123/profile te wijzigen in /api/users/124/profile om de gegevens van een ander account te lezen. Er vindt geen privilege-escalatie plaats; de aanvaller overschrijdt simpelweg de accountgrenzen binnen dezelfde laag.
Verticale IDOR
De aanvaller krijgt toegang tot objecten waarvoor hogere privileges vereist zijn dan hij bezit: toegang tot een admin-record, een beperkte configuratie-endpoint of een beheerdersfunctie 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 verzoekende gebruiker eigenaar is van die factuur, is de kwetsbaarheid structureel identiek aan een database-record-IDOR. Deze variant komt veel voor in de gezondheidszorg, financiële sector en juridische platforms waar documenten gereguleerde gegevens bevatten.
Elk van deze vormen komt overeen 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; vervallen als aparte vermelding |
| 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 (Eenvoudige uitbuiting, Wijdverspreide prevalentie) |
| MITRE CWE | CWE-639 | Authorization Bypass Through User-Controlled Key | 2025 CWE Top 25 |
OWASP Top 10-plaatsing
IDOR was een op zichzelf staande Top 10-vermelding van 2007 tot 2013. In 2017 heeft OWASP het 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-vermelding beoordeelt BOLA met de hoogste scores voor zowel uitbuitbaarheid ("Eenvoudig") als prevalentie ("Wijdverspreid"), waardoor het consequent meer gerapporteerde bevindingen oplevert dan enige andere API-kwetsbaarheid.
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 hoe de exploit in de praktijk werkt.
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 een enkele 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 verwijst naar 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 een enkele kwetsbaarheid uitgroeit tot een massaal datalek. Afhankelijk van de applicatie kan deze enumeratie snel worden voltooid. 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 het 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 is het gevolg van structurele ontwerpbeslissingen en veelvoorkomende misvattingen bij ontwikkelaars die zich opstapelen binnen applicatiearchitecturen.
Ontbrekende autorisatie en ongescope queries
De belangrijkste oorzaak is applicaties die door gebruikers aangeleverde input gebruiken om objecten op te halen zonder te controleren of de verzoekende gebruiker eigenaar is van het record. Dit komt het meest voor als ongescope databasequeries: applicaties die de volledige objecttabel opvragen (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 sequentiële 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-cheat sheet benoemt dit direct: complexe identificaties zoals GUID's 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 veel verder reikt dan 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-uitbuiting 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-incidenten 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 het eCommerce-platform van Honda 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-severiteitsbeoordelingen
De OWASP API Top 10 beoordeelt BOLA met "Eenvoudige" uitbuitbaarheid en "Wijdverspreide" prevalentie. De combinatie van eenvoudige exploitatie en brede verspreiding verklaart de #1-positie.
Deze severiteitsbeoordelingen weerspiegelen de methoden die aanvallers gebruiken om IDOR op schaal uit te buiten.
Hoe aanvallers Insecure Direct Object Reference uitbuiten
IDOR-exploitatie volgt een gestructureerde workflow die minimale technische kennis vereist.
Parametersubstitutie
De aanvaller wijzigt een identificatie naar de waarde van een andere gebruiker en observeert de respons. Door /api/users/123/profile te veranderen in /api/users/124/profile en een 200 OK-respons te ontvangen in plaats van 403 Forbidden, wordt de kwetsbaarheid bevestigd.
Geautomatiseerde enumeratie
Na bevestiging schalen aanvallers de exploit 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 krijgt toegang tot de gegevens van gebruiker B op hetzelfde privilegeniveau. 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 beïnvloeden 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. Objecttoegang op basis van argumenten creëert dezelfde kwetsbaarheid als 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 beheerst, waarbij de server geen eigendomcontrole uitvoert voordat gegevens worden teruggegeven.
Sectoren met hoog risico
De meest blootgestelde sectoren zijn die waar objectreferenties direct verwijzen naar 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 datalekken 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 manifesteert 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 het Australian Signals Directorate noemden deze case 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 maakte een aanvaller misbruik van de gebrekkige toegangscontrole om klantgegevens, inclusief geldige persoonlijke ID-nummers, te exfiltreren. 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 researchers 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 werden blootgesteld voordat leveranciers de fouten binnen enkele dagen na melding patchten.
Bug Bounty-signaal
IDOR is een consistent waardevolle bevinding 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 beslaan meer dan tien jaar aanwezigheid van IDOR in belangrijke kwetsbaarheidsraamwerken en praktijkdatalekken.
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 op zichzelf staande categorie naar een fundamenteel concept in meerdere raamwerken, en de voortdurende 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 onder 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-datalek, grootste datalek van Australië. |
| 2023 | CISA/NSA/ACSC publiceerden gezamenlijk advies AA23-208A over IDOR. BOLA behouden op API1:2023. |
| 2025 | Broken Access Control behouden 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-rapporten 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 te detecteren
IDOR is moeilijk te vinden met alleen tools omdat het redeneren over eigendom en bedrijfslogica vereist, niet alleen patroonherkenning op responscodes.
Handmatige penetratietesten (vereist)
De OWASP WSTG definieert 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.
Runtime gedragsmonitoring
Dit is de enige productieregel die realistisch IDOR in productie kan vinden. Let op deze signalen:
- Sequentiële of enumeratiepatroonverzoeken naar objectreferentie-endpoints vanuit één sessie
- Geauthenticeerde verzoeken die 200 OK retourneren voor object-ID's die niet bij de verzoekende gebruiker horen
- Groot aantal objectreferentieverzoeken 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 Authorization cheat sheet 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 naar respons. Elk pad dat een object ophaalt zonder de query te beperken tot de rechten van de geauthenticeerde gebruiker vormt een bevestigd IDOR-risico.
Het vinden van IDOR is slechts de eerste stap. Voorkomen vereist controles in uw volledige ontwikkel- en implementatiecyclus.
Hoe Insecure Direct Object Reference te voorkomen
Preventie vereist een gelaagde aanpak over ontwerp, ontwikkeling, testen en runtime monitoring.
Ontwerpfase: Modelleer autorisatie in elke functionaliteit
Neem gebroken toegangscontrole op in uw aanvalsoppervlakteanalyse 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 cheat sheet 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 Cheat Sheet stelt dat dit "moeilijk veilig te implementeren is."
- Handhaaf autorisatie op statische resources, een vaak overgeslagen vlak volgens het authorization cheat sheet.
Deze controles werken omdat ze eigendom afdwingen op 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 IDOR in bedrijfslogica.
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 runtime monitoring.
Tools voor detectie en preventie
Geen enkele tool dekt IDOR volledig. Effectieve dekking vereist een gelaagde combinatie van scannen tijdens ontwikkeling, runtime monitoring 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 actieve applicaties via HTTP/S | Vindt IDOR met multi-user configuraties | Vereist handmatige opzet van cross-account tests |
| SAST (SonarQube, Checkmarx) | White-box broncodeanalyse | Markeert ontbrekende autorisatiefuncties | Kan semantische juistheid van autorisatielogica niet verifiëren |
| IAST (Contrast Security) | In-app agent tijdens QA-testen | Runtime gedragscontext met minder false positives | Vereist geïnstrumenteerde testomgevingen |
| Handmatige pentest | Bedrijfslogica, multi-user scenario's | Enige betrouwbare methode voor complexe IDOR | Tijdrovend, vereist ervaren testers |
API-beveiliging en gedragsmonitoring
Gedragsmatige API-monitoringtools bouwen baselines van normale toegangspatronen en signaleren afwijkingen. Dit zijn de enige runtimecontroles 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 mitigatie.
- Broken Object Level Authorization (BOLA), API1:2023. Zowel IDOR als BOLA komen overeen 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 toegang te krijgen tot beheerdersfuncties, 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-opdracht; 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 het 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 | CRITIEK | 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 | CRITIEK | 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 beeldvormingsrecords 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 uitgebuite 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 over meerdere gebruikerscontexten en misbruik in productie te monitoren.
Veelgestelde vragen
IDOR is een gebrek aan handhaving van recordeigendom. 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 benamingen wijzen op dezelfde onderliggende oorzaak: ontbrekende object-niveau autorisatie.
Ja. Een aanvaller heeft meestal alleen een bereikbaar endpoint 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 meer het ophalen, bijwerken, exporteren of verwijderen van aan gebruikers gekoppelde records.
Aanvallers beginnen meestal waar de applicatie laat zien hoe objecten worden benoemd: een zichtbare 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 fout 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 dat 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.
