--- title: IDOR: når én bruker når en annens data description: IDOR er den vanligste alvorlige feilen vi finner i norske webapplikasjoner. Her er hvordan den oppstår, hvorfor ingen skanner ser den, og hva som lukker den. updated: 2026-08-21 canonical: https://glippen.no/svakheter/idor author: Erik Nilsen cwe: CWE-639 --- # IDOR: når én bruker når en annens data IDOR er når en applikasjon lar en bruker nå data som tilhører en annen, fordi den bruker en identifikator fra forespørselen uten å kontrollere hvem som spør. Dette er den vanligste alvorlige feilen i norske webapplikasjoner, og ingen automatisk skanner finner den, fordi den bare synes når man er logget inn som to forskjellige brukere. ## Hva som kan se dette Ingen automatisk skanning finner dette, og den gratis eksterne sjekken gjør det heller ikke. En skanner sammenligner det den kan nå mot en katalog over kjente svakheter, og det finnes ingen katalogoppføring for at bruker A ikke skal se fakturaene til bruker B. Den regelen gjelder hos dere og ingen andre steder. Feilen synes bare for noen som er logget inn som to brukere og prøver grensen med vilje. - Gratis ekstern sjekk: ser det ikke - Egenvurdering: ser det ikke ## Hvordan den avdekkes Feilen finnes bare innenfra, og den finnes bare når noen er logget inn som to forskjellige brukere samtidig. Det er hele grunnen til at den overlever så lenge: den ser ikke ut som noe galt fra utsiden, og den ser ikke ut som noe galt for en vanlig bruker heller. Fremgangsmåten er kjedelig og systematisk. Vi setter opp to kontoer som ikke skal se hverandres data, går gjennom applikasjonen som den ene, noterer hvert sted der noe blir hentet eller endret på vegne av en bestemt bruker, og kontrollerer deretter om den andre kontoen kommer til det samme stedet. Det er ikke et triks. Det er en liste som blir gått gjennom. Det som avgjør om vi finner den, er dekningen. En applikasjon har som regel få skjermbilder og mange endepunkter, og feilen sitter nesten alltid i et endepunkt som skjermbildet aldri viser til den som ikke skal ha det. Derfor testes API-et for seg, og ikke bare det brukergrensesnittet som ligger foran. Vi ser også etter det motsatte av en feil: steder der kontrollen finnes og virker. Det er den delen av rapporten som er verdt noe når noen spør om dere har testet tilgangskontroll, fordi den sier hva som faktisk ble prøvd. ## Hva som lukker den ### Kontrollen hører hjemme bak, ikke foran Den vanligste årsaken vi ser er at kontrollen ligger i grensesnittet. Knappen skjules for den som ikke skal ha den, og så antar den bakenforliggende koden at den som spør, har lov, fordi knappen jo var skjult. Et grensesnitt kan ikke håndheve noe. Det bestemmer bare hva som vises. Kontrollen må skje der data hentes, hver gang, uavhengig av hva som var synlig. Spørsmålet koden må stille er ikke om identifikatoren finnes, men om akkurat denne brukeren har lov til å se akkurat denne raden. ### Gjør riktig oppførsel til standarden Retting sak for sak fungerer dårlig her, fordi feilen sjelden opptrer ett sted. Er den i ett endepunkt, er den som regel i flere, fordi den kom av et mønster noen kopierte. Det som holder over tid er at kontrollen ligger i noe alle spørringer går gjennom, slik at et nytt endepunkt arver den uten at utvikleren må huske det. Da er glemsel ikke lenger en sårbarhet. ### Uforutsigbare identifikatorer er ikke en løsning Å bytte løpenummer med en tilfeldig verdi gjør det vanskeligere å gjette seg til en annens data, og det er verdt å gjøre. Men det er ikke en tilgangskontroll, det er en forsinkelse. Identifikatorer lekker gjennom lenker, eksporter, integrasjoner og logger. Bytt gjerne, men bytt i tillegg til kontrollen, ikke i stedet for den. ### Bekreft at rettingen traff En retting som ser riktig ut i koden treffer ikke alltid det som var problemet, og særlig ikke når feilen fantes flere steder. Det er derfor én retest inngår i prisen: dere får skriftlig bekreftet at det faktisk er borte, eller beskjed om at det ikke er det. ## Kilder - [OWASP Top 10: A01 Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) - [MITRE CWE-639: Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html)