Executive Summary
Hvis en kunde kan se en anden kundes ordre, hvis en medarbejder kan åbne en sag uden for sit ansvar, eller hvis en partner kan hente data via et API, som ikke tilhører dem, er problemet sjældent avanceret hacking. Det er ofte en logisk fejl i adgangskontrollen. Det er netop derfor, OWASP Top 10:2025 fortsat placerer Broken Access Control som A01, og hvorfor OWASP API Security Top 10 2023 fremhæver Broken Object Level Authorization som API1. For en dansk SMV kan den type fejl udvikle sig fra en lille udviklingsdetalje til et reelt datalæk med GDPR-konsekvenser.
Den gode nyhed er, at du ikke behøver bestille en stor teknisk øvelse for at få afklaring. En lille, defensiv pentest af API eller kundeportal kan give ledelsen et klart ja eller nej på, om data faktisk er adskilt korrekt mellem kunder, medarbejdere og partnere. Det gør pentest til et ledelsesværktøj, ikke bare en rapport til udviklere.
I praksis handler det om at afgrænse testen skarpt, formulere få acceptkriterier og kræve retest af de fund, der bliver lukket. Så får du ikke bare en liste med fejl. Du får et beslutningsgrundlag, der kan bruges til prioritering, kundetillid og dokumentation.
Hvorfor adgangskontrol er en ledelsesopgave
Når adgangskontrol fejler, er konsekvensen ikke kun teknisk. Det rammer tillid, ansvar og drift. En kundeportal eller et API er ofte tæt på virksomhedens vigtigste data: kundeoplysninger, dokumenter, priser, supporthistorik, ordrestatus eller persondata. Hvis de data kan tilgås forkert, har du både et sikkerhedsproblem og et forretningsproblem.
CISA peger i deres vejledning om misbrug af adgangskontrol på, at fejl som parameter manipulation, force browsing og svage server-side checks kan give uautoriseret adgang til data og funktioner. Det er værd at hæfte sig ved, fordi de fejl ofte opstår i helt almindelige løsninger som selvbetjening, partnerportaler og integrationer mellem systemer.
For ledelsen er spørgsmålet derfor ikke, om udviklerne kender ord som BOLA eller IDOR. Spørgsmålet er, om virksomheden kan dokumentere, at bruger A ikke kan se bruger B’s data. Hvis svaret er uklart, er en målrettet pentest ofte den hurtigste vej til vished.
Det særlige problem i API’er og kundeportaler
I en traditionel webside kan fejlen være, at man ændrer et tal i URL’en og pludselig ser en anden kundes faktura. I et API er mønsteret ofte mere stille. En bruger sender et objekt-id, et kundenummer eller et sags-id, og systemet returnerer data uden at kontrollere, om brugeren faktisk må se netop den post. Det er præcis den type fejl, OWASP beskriver under Broken Object Level Authorization.
Der er også en anden risiko i API’er. Systemet kan godt afvise adgang til hele objekter, men stadig eksponere enkelte felter, som brugeren ikke burde se. Det kan være interne noter, rabatniveauer, CPR-lignende identifikatorer eller tekniske metadata. OWASP beskriver det i API Security Top 10 2023, hvor adgangskontrol ikke kun handler om login, men også om hvilke objekter og egenskaber en bruger må få adgang til.
For en SMV er pointen enkel. Du behøver ikke have millioner af brugere for at have risiko. Du skal bare have en kundeportal, en app, et partner-login eller et API, som arbejder med forskellige datagrupper. Når det først er en del af jeres forretning, er dataadskillelse en kernekontrol.
Hvad en defensiv pentest skal svare på
En defensiv pentest af adgangskontrol skal ikke starte med alt, der kan testes. Den skal starte med det ledelsen vil vide. Kan kunder se hinandens data? Kan medarbejdere se mere end deres rolle tilsiger? Kan en partner hente oplysninger om andre kunder gennem integrationen? Kan man springe et trin i portalen over og gå direkte til en funktion, man ikke burde have adgang til?
Hvis du vil holde scope skarpt, er det ofte nok at bede om test af tre til fem roller og tre til fem datatyper. Eksempelvis kunde, intern medarbejder og ekstern partner. Samt ordredata, dokumenter, supportsager og personoplysninger. Det gør testen konkret og styrbar.
Et godt testscope kan for eksempel omfatte:
- Forsøg på at tilgå andre kunders objekter via URL, parameter eller API-kald
- Forsøg på at se skjulte eller interne felter i svar fra API’et
- Forsøg på at ændre rolle eller funktion ved at manipulere requests
- Forsøg på at åbne funktioner direkte uden korrekt rettighed
- Forsøg på adgang med kombinationer af kunde, medarbejder og partnerkonti
Hvis virksomheden samtidig arbejder med compliance, kan testen kobles til modenhedsanalyse og dokumentation, så resultatet ikke kun bliver en teknisk observation, men også et input til risikostyring og ansvar.
Sådan bestiller du en lille pentest, der giver et klart svar
Mange ledere køber for bredt ind og ender med en rapport, som er svær at bruge. Her er det bedre at være mere konkret. Bed om en defensiv pentest med klart formål, tydelige roller og få acceptkriterier. Så ved alle, hvad et tilfredsstillende resultat er.
Du kan bruge denne enkle bestillerliste:
- Afgræns én portal eller ét API og højst fem centrale brugerflows.
- Beskriv præcist hvilke roller der skal testes, for eksempel kunde, supportmedarbejder og partner.
- Udpeg de datatyper, der ikke må kunne krydses mellem roller eller kunder.
- Krav om et executive summary på almindeligt dansk.
- Krav om ja eller nej-vurdering af dataadskillelse for de valgte flows.
- Krav om retest efter udbedring.
Hvis du kombinerer dette med et indledende sikkerhedstjek, kan du ofte få ryddet de mest oplagte opsætningsfejl af vejen først. Det gør den efterfølgende pentest mere værdifuld, fordi tiden bruges på logiske fejl og ikke banale konfigurationsproblemer.
Acceptkriterier ledelsen faktisk kan bruge
Den største forskel på en brugbar og en ubrugelig pentest ligger ofte i acceptkriterierne. Hvis målet bare er at “teste sikkerheden”, bliver resultatet diffust. Hvis målet derimod er et klart svar på dataadskillelse, bliver rapporten meget lettere at omsætte til handling.
For en ledelsesvenlig defensiv pentest af API eller kundeportal kan acceptkriterierne være:
- Ingen kunde kan se, hente eller ændre andre kunders data via portal eller API.
- Ingen medarbejderrolle kan tilgå data uden for defineret arbejdsbehov.
- Ingen partnerkonto kan læse eller ændre data uden for egen aftalt adgang.
- Direkte kald til funktioner og endpoints bliver afvist korrekt ved manglende rettighed.
- Retest dokumenterer, at fund er lukket og ikke kan gentages.
Det er også her, pentest bliver relevant for GDPR. Datatilsynet beskriver i sin vejledning om håndtering af brud på persondatasikkerheden, at brud kan omfatte fortrolighed, integritet og tilgængelighed. Hvis en bruger får adgang til personoplysninger, vedkommende ikke burde se, er det ikke bare en teknisk fejl. Det kan være et sikkerhedsbrud, som skal vurderes og eventuelt håndteres efter GDPR.
Pentest er mest værd, når retest er aftalt fra starten
En defensiv pentest giver mest værdi, når den slutter med bevis for forbedring. Derfor bør retest ikke være et tilvalg, der glemmes senere. Det bør være en del af opgaven fra starten. Først når de konkrete fund er genafprøvet, har du dokumentation for, at virksomheden faktisk har lukket risikoen.
Retest er især vigtig ved adgangskontrol, fordi fejlene ofte er logiske. En udvikler kan lukke ét endpoint og overse et andet, som bruger samme svage kontrolmønster. Derfor er det nyttigt at bede om både verifikation af det konkrete fix og stikprøver på beslægtede funktioner.
For ledelsen giver det en enkel gevinst. I går fra “vi tror, det er løst” til “vi har testet, at det er løst”. Det er præcis den type ro i maven, som gør en pentest relevant uden at gøre den tung. Hvis du vil løfte det videre organisatorisk, kan en kort workshop for ledelse eller et mere fast setup via Forkant™ hjælpe med at gøre ansvar, prioritering og opfølgning til en fast rutine.
Næste skridt: få et ja eller nej på dataadskillelse
Hvis din virksomhed har en kundeportal, selvbetjening eller et API med følsomme kunde- eller partnerdata, er det oplagte næste skridt at definere et lille scope med få roller, få flows og klare acceptkriterier. Målet er ikke en stor øvelse. Målet er et enkelt svar: Er data adskilt korrekt eller ikke?
Start med de flows, der betyder mest for kundetillid og persondata. Aftal derefter executive summary, acceptkriterier og retest på forhånd. Så bliver en defensiv pentest et praktisk ledelsesværktøj, der skaber overblik og handlekraft i stedet for støj.