Kode og sikkerhed

Sikkerhedstest: kan appens grænser holde til en rigtig prøvelse?

En grøn build og en automatisk scanning viser ikke, om en kunde kan læse en anden kundes data, om et skjult API accepterer en ulovlig statusændring, eller om en almindelig bruger kan kalde en adminfunktion direkte. En afgrænset sikkerhedstest prøver den kørende app, dens roller og forretningsregler — med udtrykkelig tilladelse, kontrollerede testdata og en plan for at rette fundene.

Udgivet 6. oktober 2026 · Ca. 12 minutters læsetid

Det korte svar

Beskriv præcist, hvilke domæner, API'er, roller, data og handlinger der må testes. Opret repræsentative testkonti, aftal stopkriterier og kontaktperson, og vælg testscenarier ud fra appens egne største risici. Rapporten skal gøre hvert fund reproducerbart og koble det til en reel konsekvens. Ret årsagen, tilføj en test mod tilbagefald, og få alvorlige fund afprøvet igen.

En penetrationstest er ikke et sikkerhedscertifikat. NCSC understreger, at en velafgrænset test giver viden om de testede dele på testtidspunktet. Nye ændringer, dele uden for scope og fejl, som testen ikke fandt, kan stadig være sårbare.

Skeln mellem scanning, sikkerhedstest og penetrationstest

Begreberne bruges ofte løst. Aftal derfor leverancen i konkrete testområder og beviser frem for blot at købe noget, der kaldes et pentest.

Kontrol	Styrke	Begrænsning
Automatisk scanning	Finder kendte mønstre, udsatte komponenter og visse konfigurationsfejl gentageligt	Forstår sjældent virksomhedens roller, dataejerskab og arbejdsgange
Målrettet sikkerhedstest	Afprøver konkrete kontroller, misbrugsscenarier og negative forløb	Dækker kun det valgte scope og den afsatte tid
Penetrationstest	Kombinerer teknikker for at vise, om svagheder kan udnyttes og med hvilken virkning	Er et øjebliksbillede og kan ikke erstatte løbende udviklings- og driftskontroller

OWASP ASVS kan bruges som et kravgrundlag for, hvad der skal verificeres, mens OWASP WSTG beskriver metoder og testscenarier. Ingen af dem bør bruges som en ukritisk liste, hvor alle apps får samme dybde.

Vælg tidspunkt og dybde efter konsekvensen

En lille intern app med ufølsomme data kræver ikke nødvendigvis samme test som en flerbrugerportal med betaling, persondata eller adgang på tværs af virksomheder. Overvej en målrettet, uafhængig gennemgang, når appen eksempelvis får eksterne brugere, håndterer følsomme oplysninger eller giver handlinger stor økonomisk eller driftsmæssig virkning.

Før bred adgang: Test de vigtigste grænser, før mange medarbejdere eller kunder bliver afhængige af dem.
Efter væsentlige ændringer: Ny identitet, betaling, filhåndtering, integration, tenantmodel eller adminfunktion kan ændre angrebsfladen.
Efter et alvorligt fund: Retest skal bekræfte både den konkrete rettelse og lignende kodeveje, der kan have samme årsag.
Når kravene kræver det: Kunde-, branche- eller myndighedskrav skal oversættes til et tydeligt scope og dokumenteret resultat.

Skriv testens spilleregler før nogen angriber appen

Aktiv sikkerhedstest kan påvirke data, mail, betaling, køer og leverandørgrænser. Den skal derfor være udtrykkeligt godkendt af den rette ejer og afgrænset skriftligt. Kontrollér også reglerne hos cloud-, hosting- og tredjepartsleverandører, før deres systemer eller grænseflader indgår.

Teknisk scope: Præcise hosts, API'er, appversion, mobilklienter, cloudressourcer og integrationer — plus det, der udtrykkeligt er uden for scope.
Tilladte metoder: Aftal om eksempelvis automatiserede kald, filupload, rolleændringer og forsøg på dataadgang må gennemføres, og hvilke handlinger der er for risikable.
Tid og stop: Angiv testvindue, overvågning, ansvarlig kontakt, stopkriterier og hvad der sker ved nedbrud eller fund med akut risiko.
Data og beviser: Brug kontrollerede testdata, aftal hvordan screenshots, requests, tokens og rapporter beskyttes, deles og slettes.
Leverance: Aftal rapportformat, risikovurdering, gennemgang med udvikleren, frist for kritiske fund og hvilke rettelser der retestes.

Opret konti, der kan bevise adgangsgrænserne

En test med én administratorkonto kan ikke vise, om en almindelig bruger er korrekt afgrænset. Opret kun de testidentiteter, der er nødvendige, men lad dem repræsentere de roller og datagrænser, som appen faktisk skal håndhæve.

En anonym bruger til offentlige sider, formularer og API'er.
To almindelige brugere i samme virksomhed til ejerskab mellem personer og teams.
Brugere i to forskellige virksomheder, hvis appen adskiller kundedata.
En relevant leder-, support- eller administratorrolle uden flere rettigheder end nødvendigt.
En deaktiveret, udløbet eller fratrådt bruger til test af gamle sessioner og tilbagekaldelse.

Giv testeren nok viden til at bruge tiden rigtigt. Kildekode, API-beskrivelse, systemkort, roller og kendte risici kan gøre en test mere målrettet. En lukket black-box-test og en åben test besvarer forskellige spørgsmål; mindre information gør ikke automatisk testen mere realistisk eller komplet.

Test appens egne grænser — ikke kun kendte sårbarheder

OWASP WSTG dækker blandt andet identitet, login, autorisation, sessioner, input, fejl, browserkode, API'er og forretningslogik. Udvælg de dele, der kan føre til reel skade i den konkrete app.

Identitet og session

Afprøv login, MFA, nulstilling, invitationer, sessionsudløb, tilbagekaldelse og gamle eller stjålne sessioners muligheder.

Rolle og datapost

Forsøg lovlige handlinger på den forkerte virksomheds, brugers eller sags data gennem både brugerflade og direkte API.

Input og integrationer

Kontrollér felter, filer, redirects, webhooks, eksterne svar og fejltilstande uden at udføre destruktive handlinger.

Forretningslogik

Prøv spring i workflow, ændrede beløb, gentagne handlinger, samtidighed og grænser, som en almindelig scanner ikke kender.

Beskyt drift og persondata under testen

Et produktionslignende testmiljø er ofte det sikreste udgangspunkt, men forskelle i identitet, netværk, headers og cloudkonfiguration kan gøre visse kontroller produktionsspecifikke. Beslut miljø pr. testområde i stedet for at antage, at alt skal køres samme sted.

Brug syntetiske data: Opret fiktive personer, filer, ordrer og betalinger, der kan genkendes og ryddes op.
Isolér sideeffekter: Brug leverandørernes testtilstande, afgræns mailmodtagere, og undgå rigtige udbetalinger, bookinger og kundebeskeder.
Overvåg mens testen kører: Logs, alarmer og kontaktperson skal kunne skelne aftalt testtrafik fra et reelt angreb eller driftsproblem.
Hav gendannelse klar: Kend backup, rollback og stopprocedure før aktive forsøg på ændringer, upload eller belastning.
Beskyt rapporten: Beviser kan indeholde interne URL'er, bruger-id'er, arkitektur og midlertidige credentials. Del dem efter behov og tilbagekald testadgang bagefter.

Kræv en rapport, der kan omsættes til rettelser

En alvorlighed uden kontekst hjælper hverken virksomheden eller udvikleren. NIST beskriver testarbejdet som planlægning, gennemførelse, analyse og afhjælpning. Hvert fund bør derfor være tydeligt nok til, at en anden kan forstå risikoen, rette årsagen og kontrollere resultatet.

Omfang og begrænsninger: Hvilken version, hvilke hosts, roller og funktioner blev faktisk testet, og hvad blev ikke dækket?
Bevis og reproduktion: Beskriv forudsætninger og sikre trin uden at lægge aktive secrets i rapporten.
Forretningsvirkning: Forklar hvilke data, brugere, penge eller driftsfunktioner en udnyttelse kan påvirke.
Årsag og udbredelse: Peg på den svage kontrol og lignende steder, der skal undersøges — ikke kun den ene URL.
Forslag og verifikation: Beskriv det ønskede sikkerhedsresultat, og aftal hvordan rettelsen skal retestes.

Luk fund med rettelse, regressionstest og retest

1. Bekræft og begræns. Stop akut misbrug med en afgrænset kontrol, hvis fundet allerede kan udnyttes, uden at skjule behovet for en varig rettelse.
2. Ret årsagen. Flyt eksempelvis adgangskontrollen til den fælles serverfunktion frem for at lappe én knap eller ét endpoint.
3. Søg samme mønster. Gennemgå beslægtede roller, ressourcer, API'er og kodeveje for den samme fejltype.
4. Tilføj en varig test. Gør det afviste misbrugsscenarie til en automatiseret eller fast manuel regressionstest, hvor det er praktisk.
5. Retest i aftalt miljø. Kontrollér både at angrebet afvises, og at legitime brugere stadig kan gennemføre deres arbejde.
6. Registrér rest-risiko. Udsatte eller accepterede fund skal have ejer, begrundelse, beskyttende tiltag og dato for ny vurdering.

Typiske fejl

En scanner kaldes et pentest: Rapporten indeholder generiske headers og pakkeversioner, men ingen test af roller, data eller forretningslogik.
Kun forsiden er i scope: Admin, API, baggrundsjob, filområder og integrationer er usynlige for testen.
Alle tester som administrator: Den rolle, som allerede må mest, afslører ikke manglende grænser for almindelige brugere.
Produktion angribes uden spilleregler: Mails, betalinger, data og alarmer påvirkes, før nogen kan stoppe testen.
Rapporten deles som et almindeligt bilag: Et nyttigt angrebskort ender bredt i indbakker og mapper uden adgangs- eller sletteplan.
Kun det viste endpoint rettes: Den fælles manglende adgangskontrol findes fortsat andre steder.
Ingen fund kaldes sikker: Resultatet glemmer tidsgrænsen, udeladelserne og alle fremtidige ændringer.

Tjekliste før en sikkerhedstest bestilles eller gennemføres

☐ Appens vigtigste data, handlinger, roller, integrationer og misbrugsscenarier er kortlagt.
☐ Testens mål er skrevet som konkrete spørgsmål frem for et generelt ønske om “at være sikker”.
☐ Præcise hosts, API'er, versioner og tredjepartsgrænser er angivet som inde eller ude af scope.
☐ Den rette systemejer har givet udtrykkelig tilladelse, og relevante leverandørregler er kontrolleret.
☐ Tilladte og forbudte metoder, testvindue, stopkriterier og akut kontakt er aftalt.
☐ Repræsentative testkonti dækker bruger-, rolle- og tenantgrænser uden unødige rettigheder.
☐ Testdata, mail, betaling, filer og andre sideeffekter er isoleret eller tydeligt kontrolleret.
☐ Logs, alarmer, backup og rollback er klar, før aktive tests begynder.
☐ Rapporten skal beskrive scope, bevis, årsag, virkning, prioritet, forslag og begrænsninger.
☐ Rapport, screenshots, requests og testcredentials har aftalt adgang, opbevaring og sletning.
☐ Hvert fund får ejer, beslutning og frist; alvorlige fund har en aftalt retest.
☐ Rettelser suppleres med regressionstest, og midlertidige konti og nøgler lukkes bagefter.

Relaterede guides

Trusselsmodel til at vælge de vigtigste testscenarier Automatisk sikkerhedsscanning i ændringsflowet Teststrategi for kritiske brugerrejser og regressioner Roller, rettigheder og adgang til den enkelte datapost Driftsberedskab ved et akut sikkerhedsfund Se hele guidebiblioteket

Officielle kilder

Testmetode og dybde skal passe til appens teknologi, trusselsmodel og konsekvens. De tekniske råd er kontrolleret mod aktuelle primærkilder. Brug den stabile, versionerede OWASP WSTG til testscenarier, og kontrollér altid den konkrete platforms vilkår før aktiv test.