Executive Summary
Broken access control handler i praksis om ét forretningsspørgsmål: Kan den forkerte person se eller gøre noget, de ikke burde i jeres kundeportal, leverandørportal eller interne webapp? Hvis svaret er ja, er risikoen ikke kun teknisk. Det kan blive til datalæk, brud på fortrolighed, fejl i ordreflow og en ledelsessag, fordi kunder, medarbejdere eller leverandører får adgang til data, som ikke er deres. OWASP placerer fortsat Broken Access Control som den mest kritiske web-risiko, og Verizon DBIR 2025 viser, at webapplikationer og identitetsrelaterede angreb stadig fylder meget i virkeligheden. OWASP Top 10 og Verizon DBIR 2025
For ledelsen er pointen enkel: En portal behøver ikke at være “hacket” i filmforstand for at skabe skade. Det kan være nok, at en kunde kan ændre et tal i en URL, genbruge et link, åbne en ordre, hente en PDF eller bruge en funktion, som skulle have været begrænset til en anden rolle. Sådan opstår nogle af de dyreste fejltyper, fordi problemet rammer direkte ind i fortrolighed, tillid og drift.
Løsningen er ikke at læse kildekode eller tale i specialudtryk. Løsningen er at få testet adgangsstyringen som et konkret forretningsscenarie: Kan kunde A se kunde B’s data? Kan en medarbejder se mere end nødvendigt? Kan en leverandør få adgang uden for sit scope? En målrettet pentest af adgangsstyring bør ende i et klart ja eller nej, tydelige acceptkriterier og en fast retest, så du ved, om kontrollen virker i praksis.
Hvad broken access control betyder i en dansk virksomhed
Broken access control betyder, at systemet ikke konsekvent håndhæver, hvem der må se, oprette, ændre eller slette hvad. Det lyder teknisk, men i hverdagen er det meget konkret. En kundeportal viser måske den forkerte faktura. Et ordresystem lader en bruger åbne en anden kundes sag. En intern webapp giver en projektleder adgang til HR-data. En leverandør kan måske se mere end egne tickets, lagerdata eller kontraktoplysninger.
OWASP fremhæver broken access control som nummer 1 blandt de vigtigste applikationsrisici. I 2021-materialet fremgår det, at 94 procent af de testede applikationer blev undersøgt for denne type fejl, og at kategorien havde flest registrerede forekomster i datasættet. OWASP A01 Broken Access Control
For en ejerleder er det afgørende ikke navnet på fejlen, men konsekvensen. Hvis den forkerte bruger får adgang, kan det føre til kundetab, intern uro, ekstra juridisk arbejde og i værste fald anmeldelsespligt ved brud på persondatasikkerheden. Derfor hører adgangsstyring hjemme i samme ledelsesrum som betalingskontrol, leverandørstyring og beredskab.
Hvorfor kundeportaler og interne webapps er særligt udsatte
Kundeportaler og interne webapps ændrer sig ofte hurtigere end de kontrolmekanismer, der skal beskytte dem. Nye kunder, nye roller, nye leverandører, nye funktioner og nye integrationer kommer til løbende. Når tempoet er højt, opstår der let forskel mellem det, virksomheden tror er tilladt, og det systemet faktisk tillader.
Det gælder især i løsninger, hvor samme platform bruges af flere kundekonti, afdelinger eller eksterne samarbejdspartnere. Her bliver adgangsstyring hurtigt en kombination af roller, datafiltre, API-kald, dokumentvisning og gamle undtagelser. Det er netop derfor, at OWASP Web Security Testing Guide anbefaler systematisk test af autorisation og adgangskontrol, ikke kun login.
Verizon DBIR 2025 peger samtidig på et fortsat højt tryk fra webapplikationsangreb og identitetsrelaterede hændelser. Det understreger et vigtigt ledelsespoint: Risikoen ligger ikke kun i at holde uvedkommende ude. Risikoen ligger også i, at legitime brugere får for brede rettigheder, eller at applikationen ikke tjekker adgangen hver gang den viser eller ændrer data. DBIR 2025 Executive Summary
Det er også et krav om passende sikkerhed
Adgangsstyring er ikke kun god praksis. Det hænger også tæt sammen med krav om passende sikkerhed. Datatilsynet har flere gange slået fast, at rettighedsstyring skal forhindre uautoriseret adgang, og at passende sikkerhed normalt indebærer løbende kontrol af, om adgange er begrænset til brugere med sagligt behov. Tilsynet peger også på GDPR artikel 32, stk. 1, litra d, om regelmæssig afprøvning, vurdering og evaluering af sikkerhedsforanstaltningernes effektivitet. Datatilsynet om AULA-afgørelser
I en nyere afgørelse om Digitaliseringsstyrelsen fremhæver Datatilsynet, at test af systemer bør tage udgangspunkt i brugsscenarier og funktioner, før systemet sættes i drift, og at utilstrækkelig test kan være i strid med artikel 32. Det er værd at bemærke, fordi rettighedsstyring netop er en grundlæggende funktion i portaler og sagssystemer. Datatilsynet om Digitaliseringsstyrelsen
Hvis din virksomhed arbejder med GDPR, NIS2 og modenhedsanalyse, er dette derfor et område, hvor dokumenteret test giver mere værdi end generelle hensigtserklæringer. Det samme gælder, hvis du vil være bedre forberedt på kundekrav, revision eller bestyrelsesdialog om adgangsstyring.
Sådan ser fejlen ud i praksis
Forestil dig en kundeportal, hvor kunder kan hente fakturaer og ordrestatus. Hvis kunde A kan ændre et kundenummer i adresselinjen og se kunde B’s dokumenter, er det et klassisk eksempel. Det samme gælder, hvis en medarbejder med supportrolle kan åbne alle kunders sager, selv om rollen kun burde give adgang til egen portefølje.
I interne systemer ser vi ofte fejlen som “for meget adgang over tid”. En person skifter rolle, men beholder gamle rettigheder. En projektleder får midlertidig adgang til et område og mister den aldrig igen. En leverandør får adgang til at løse én opgave, men kan også se data om andre kunder eller andre afdelinger. Problemet er ikke kun, om adgangen kan misbruges. Problemet er, at virksomheden mister kontrollen med, hvem der kan se hvad.
Det er også derfor en almindelig sårbarhedsscanning ikke er nok. Scanning kan være et godt første skridt og passer fint sammen med et sikkerhedstjek, men den kan sjældent svare på, om kunde A kan se kunde B’s data. Det kræver scenariebaseret test, hvor man tænker som en angriber og som en almindelig bruger på samme tid.
Mini-scope til en pentest af adgangsstyring
Hvis du vil bestille en målrettet test, så hold scopet enkelt og forretningsnært. Et godt mini-scope til en første test kan være én kundeportal eller intern webapp, tre til fem typiske brugerroller og tre forretningskritiske dataområder som kundedata, ordrer, dokumenter eller medarbejderoplysninger.
- Udvalgte roller: kunde, medarbejder, administrator, leverandør
- Udvalgte funktioner: visning, søgning, eksport, upload, godkendelse, ændring, sletning
- Udvalgte dataobjekter: kundeprofiler, ordrer, bilag, tickets, kontrakter, rapporter
- Udvalgte grænseflader: webapp, mobilvisning, API-kald, download-links
- Udvalgte scenarier: horisontal adgang mellem kunder, vertikal adgang mellem roller, gamle rettigheder, direkte links og delte dokumenter
Det ligger tæt op ad anbefalingerne i NIST SP 800-115, som beskriver planlagt og kontrolleret sikkerhedstest, og i CISA’s guidance om penetration testing, hvor testen skal være aftalt, afgrænset og brugbar for beslutningstagere.
8 ja eller nej-spørgsmål ledelsen bør stille
Du behøver ikke spørge efter exploit-kæder eller framework-navne. Spørg i stedet efter svar, der kan bruges i drift og ledelse.
- Kan kunde A se, hente eller ændre kunde B’s data ved at ændre et link, et id eller en forespørgsel?
- Kan en almindelig medarbejder få adgang til funktioner, der burde være begrænset til ledelse eller administration?
- Kan en leverandør se andre kunders eller afdelingers data end dem, vedkommende arbejder for?
- Bliver adgang kontrolleret på serversiden hver gang, eller stoler løsningen på skjulte knapper og brugerfladen?
- Fungerer adgangskontrol ens i webapp, API og dokumentdownload?
- Findes der gamle, midlertidige eller glemte rettigheder, som giver mere adgang end nødvendigt?
- Bliver fejl afvist tydeligt, eller kan en bruger stadig få data ud ved direkte kald?
- Er fundne fejl lukket og retestet, så I kan dokumentere effekten?
Hvis du vil sætte testen ind i en større styringsramme, kan det give mening at koble den med en workshop for ledelse eller en modenhedsanalyse, så ansvar, ejerskab og opfølgning bliver tydelige.
Klare acceptkriterier gør testen brugbar
Mange pentest-rapporter fejler ikke på teknik, men på brugbarhed. Ledelsen har brug for en test, der ender i klare acceptkriterier. Ellers bliver resultatet bare endnu en rapport i mappen.
- Ingen bruger må kunne se, hente, ændre eller slette data, som tilhører en anden kunde, afdeling eller leverandørrelation, uden eksplicit forretningsbehov
- Alle adgangstjek skal håndhæves på server- eller API-niveau, ikke kun i brugerfladen
- Samme rolle skal have samme begrænsning på tværs af portal, API, dokumentvisning og eksport
- Midlertidige og historiske rettigheder skal være fjernet eller dokumenteret godkendt
- Alle kritiske og høje fund skal retestes og lukkes inden go-live eller inden aftalt deadline
Det gør også retest til en naturlig del af leverancen. Hvis du vil læse mere om, hvordan rapport og opfølgning bør se ud, er bloguniverset og især de tidligere pentest-indlæg et godt sted at starte.
Næste skridt: Gør adgangsstyring til en ja eller nej-test
Hvis din virksomhed har en kundeportal, et ordresystem, en partnerløsning eller en intern webapp, så vælg én løsning og afgræns testen til de mest følsomme data og de vigtigste roller. Bed om et mini-scope, de 8 ja eller nej-spørgsmål ovenfor, fem acceptkriterier og en retest som fast del af forløbet. Så får du et svar, der kan bruges i ledelsen: Kan den forkerte person se eller gøre noget, de ikke burde?
Det er et mere værdifuldt første skridt end endnu en generel statusrapport, fordi det giver dig dokumentation for, om jeres adgangsstyring faktisk virker. Og hvis den ikke gør, ved du præcis, hvor du skal starte.