Svakhet
Tenant-isolasjon: når én kunde kan se en annen
Tenant-isolasjon er skillet som sikrer at kunder som deler den samme installasjonen av en tjeneste, ikke kan nå hverandres data.
Det er tilgangskontroll ett nivå over brukeren, og konsekvensen er tilsvarende større: én feil her rammer ikke én bruker, men potensielt hele kundelisten.
CWE-639 · Sist oppdatert 2026-11-01
Synlighet
Hva som kan se dette, og hva som ikke kan
Dette er ikke noe en skanning finner, og det er verdt å vite hvorfor.
Dette er usynlig utenfra. En passiv sjekk av domenet sier ingenting om hvordan applikasjonen skiller kundene fra hverandre, og en skanner har ingen måte å vite hvem som skulle hatt tilgang til hva. Feilen er stille også innenfra: alt ser riktig ut for den vanlige brukeren, helt til noen setter opp to kunder og prøver grensen med vilje.
- Gratis ekstern sjekk
- ser det ikke
- Egenvurdering
- ser det ikke
Slik finner vi det
Hvordan denne feilen faktisk avdekkes
Prosessen, ikke fremgangsmåten for å utnytte den.
Tenant-isolasjon er tilgangskontroll på et nivå over brukeren. Spørsmålet er ikke om Kari kan se Pers data, men om alt hos kunde A er utilgjengelig for alle hos kunde B. Det er den samme klassen feil som IDOR, med en konsekvens som er en helt annen: én feil rammer ikke én bruker, men hele kundelisten.
Vi tester det med to kunder vi setter opp selv, ikke med to brukere hos samme kunde. Deretter går vi gjennom det samme som ellers, med ett tillegg: alt som identifiserer en kunde blir kontrollert overalt der det kan komme inn. Feilen sitter sjelden i innloggingen. Den sitter i et sted der kundetilhørigheten ble lest fra noe klienten sendte inn, i stedet for fra sesjonen.
Rapporter, eksporter, søk, vedlegg, varsler og bakgrunnsjobber er der vi finner den oftest. Det er funksjoner som er bygget etter at isolasjonen var på plass, og som henter data på en litt annen måte enn resten.
Integrasjoner mot andre systemer er den andre. Data som går ut til et tredje system og kommer tilbake, har vært utenfor det som håndhever isolasjonen, og kommer ofte tilbake uten den.
Retting
Hva som lukker den
Rammeverksuavhengig først. Detaljene avhenger av hva dere har, og dem tar vi sammen.
Kundetilhørighet leses aldri fra forespørselen
Hvilken kunde en innlogget bruker tilhører, er noe systemet vet fra sesjonen. Kommer det inn som en parameter, en header eller et felt i en forespørsel, kan det endres av den som sender den.
Dette er den enkeltårsaken vi ser oftest, og den er som regel innført med gode hensikter: noen trengte å kunne bytte kontekst, for eksempel for support, og løsningen ble et felt alle kan sende.
Isolasjonen hører hjemme i datalaget
Ligger kontrollen i hver enkelt spørring, er den så sterk som utviklerens hukommelse den dagen spørringen ble skrevet. Det holder en stund, og så kommer det en rapport eller en eksport til.
Det som holder er at kundeavgrensningen ligger i laget alle spørringer går gjennom, slik at en spørring uten avgrensning enten er umulig å skrive eller feiler høylytt. Hvordan det gjøres, avhenger av basen og rammeverket dere har, og det er en av tingene vi går gjennom sammen etterpå.
Se over det som kjører uten en bruker
Bakgrunnsjobber, planlagte oppgaver og administrasjonsverktøy kjører ofte med utvidede rettigheter og uten en innlogget bruker å avgrense mot. Det er en legitim nødvendighet, og det er samtidig stedet der isolasjonen oftest er slått av permanent.
Gå gjennom hver av dem og still ett spørsmål: hvis denne jobben fikk feil kunde-id, hva ville skje. Svaret bør være at den stopper.
Dokumenter at det er prøvd
Selger dere til enterprise eller offentlig sektor, kommer spørsmålet om kundeseparasjon i sikkerhetsskjemaet før eller siden, og det er formulert som et spørsmål om hva dere har gjort for å kontrollere det. Da er en test med to oppsatte kunder og en rapport som sier hva som ble prøvd, et konkret svar der de fleste leverandører har en formulering.
Skal noen rette det nå
Dere har fått et funn om at én bruker kan nå en annens data. Her er rekkefølgen som lukker det for godt, og de tre rettingene som ser riktige ut og ikke er det.
Fra oppdrag
Funn fra virkelige tester
Skrevet av Erik Nilsen etter autoriserte oppdrag. Navnene i skrivene er oppdiktet og detaljene sanert, funnene er fra ekte tester.
- Firebase-gulvet ga etter: når tenantsitteren bor i én samling
Ekstern test av en skattetjeneste på Firebase og Google Cloud Run, der en samling med brukerprofiler kunne leses ut i sin helhet og dokument-API-et lot en innlogget bruker se filoversikten til andre kunder og skrive filer hos dem.
- Fakturaen som aldri ble betalt: billing-bypass i en Supabase edge function
En Supabase-app ga et aktivt enterprise-abonnement uten betaling, og regelen som skulle hindre én kunde i å skrive data hos en annen, brøt sammen to ganger i løpet av oppdraget før den holdt.
- Cross-tenant-funnet overlevde verifiseringen, og var verre
Et booking-API for skoler svarte uten innlogging og ga ut bookinger og passord i klartekst på tvers av 56 skoler, og den negative kontrollen viste at tilgangskontrollen ikke kontrollerte noe.
- Kjernen holdt, eiendommen ikke
Retest av regnskapsplattformen fra juli med bredere omfang: isolasjonen i API-et holdt fortsatt, men en opplastet fil kombinert med manglende CSRF-vern lot en bruker hos én kunde overta API-nøkkelen til en bruker hos en annen.
- Da cross-tenant-funnet ikke overlevde verifisering
Et oppslag som så ut som et brudd mellom to kunder i en SaaS, falt bort da det ble prøvd fra en konto som ikke eide objektet, og skrivet viser hele verifiseringen og de tre funnene som ble forkastet.
- Isolasjonen holdt, autorisasjonen sprakk: pentest av en regnskaps-SaaS
Autorisert test av et regnskaps-API med mange kunder på samme plattform: skillet mellom kundene holdt på alle veier som ble prøvd, mens autorisasjonsmodellen rundt hadde tre reelle hull.
Testes i
Tjenestene som ser etter dette
Prisen står på hver enkelt, og den er den samme uansett hvor mye vi finner.
- App-sjekk
En fokusert førstetest av én webapp eller ett API, med to roller i ett miljø. Vi logger inn og ser etter det som betyr mest: kan noen nå data eller handlinger de ikke skal.
- Pentest av app og API
Vi tester applikasjonen og API-et deres som innloggede brukere, med opptil fire roller, og ser etter det som lar noen nå data eller handlinger de ikke skal. Dere får et attestbrev som kan sendes til kunden.
- Pentest av større plattform
For plattformer med flere apper eller API-er og mange roller. Vi tester opptil tre applikasjoner eller API-er, også API-et bak en mobilapp, med opptil ti roller. Dere får et attestbrev som kan sendes til kunden.
- Glippen Løpende
En pentest av app og API hvert år, retest hvert kvartal og overvåking av opptil fem domener. For dere som får spørsmål om sikkerhet fra kundene hele året.
Videre