Penetrationstest: har din webapp brug for en?

Din webapp har brug for en penetrationstest når nogen udefra kræver det (en stor kunde, et udbud, en investor eller en certificering), eller når den behandler følsomme persondata eller kortdata. Har du ingen af delene, får du som regel mere for pengene ved først at opdatere systemet, stramme adgangsstyringen og få et code review. Selve testen skal laves af et uafhængigt sikkerhedsfirma, mens udviklerens opgave er at gøre appen klar før og rette fundene bagefter.

Jeg er udvikler, ikke pentester. Guiden er skrevet fra udviklerens side af bordet: hvornår testen er pengene værd, hvordan du undgår at betale testere for at finde det åbenlyse, og hvad der skal ske når rapporten lander.

Den korte version: har du brug for en pentest?

Brug tabellen til at finde din situation. Står du i flere rækker, er det den mest krævende der afgør det.

Min tommelfingerregel: Kan du pege på en person eller et krav der vil se rapporten, eller vil et datalæk ramme dine brugere hårdt, så er testen pengene værd. Ellers starter du med det grundlæggende.

En penetrationstest er kun én brik i den løbende sikkerhed. Opdateringer, backup og overvågning gennemgår jeg i den komplette guide til drift og vedligehold af webapps.

Hvad en penetrationstest er, og hvad den ikke er

En penetrationstest (ofte forkortet pentest) er et kontrolleret angreb på din webapp, udført af sikkerhedsfolk med din skriftlige tilladelse. Målet er at finde hullerne før nogen med dårlige hensigter gør det, og at vise hvor langt man kan nå med hvert af dem. Resultatet er en rapport med fund, alvorlighed og anbefalinger.

Tre ting bliver ofte blandet sammen:

• Sårbarhedsscanning: et automatisk værktøj leder efter kendte fejl og forældede komponenter. Det er billigt og hurtigt, men finder ikke logiske fejl, fx at en bruger kan se en anden kundes fakturaer ved at ændre et tal i adresselinjen.
• Code review: en udvikler læser koden og vurderer sikkerhed, struktur og kvalitet indefra. Det finder mange af de samme fejl tidligere og billigere, men beviser ikke at de kan udnyttes. Hvornår det er det rigtige valg, gennemgår jeg i 9 situationer hvor du har brug for et code review udefra.
• Penetrationstest: et menneske angriber den kørende app med en angribers værktøjer og tankegang og prøver at kæde små fejl sammen til store.

Testerne arbejder typisk på en af tre måder. Ved black box får de intet at vide på forhånd. Ved grey box får de testbrugere og lidt dokumentation. Ved white box får de også adgang til koden. Til de fleste webapps anbefaler jeg grey box: testerne bruger tiden på at finde huller i stedet for at gætte sig til hvordan appen virker, og du får mere ud af hver testdag.

Hvornår en pentest er nødvendig

Kunder og udbud kræver det

Den mest almindelige grund er et krav udefra. Sælger du til større virksomheder, kommer der typisk et sikkerhedsspørgeskema før kontrakten, og et af spørgsmålene er om systemet er penetrationstestet inden for det seneste år. Offentlige udbud og kunder med en ISO 27001-certificering (den internationale standard for informationssikkerhed) kan stille lignende krav til deres leverandører. Her er spørgsmålet ikke om testen er teknisk nødvendig, men om du vil have kunden.

Får du kravet, så spørg præcis hvad kunden vil se: hele rapporten, et resumé eller en erklæring fra testfirmaet. Det påvirker både prisen og hvordan du deler resultatet. Er kunden omfattet af NIS2, kan kravene til dig som leverandør blive skrappere, og det gennemgår jeg i NIS2 og din webapp.

Persondata og GDPR

Databeskyttelsesforordningen bruger ikke ordet penetrationstest. Men artikel 32 i forordningen kræver, alt efter hvad der er relevant, en procedure for regelmæssigt at afprøve, vurdere og evaluere om dine tekniske og organisatoriske sikkerhedsforanstaltninger virker. For en webapp med almindelige kundekonti kan det være automatisk scanning, faste opdateringer og et review. Behandler du helbredsoplysninger, CPR-numre eller økonomiske data, er en ekstern test den mest overbevisende dokumentation hvis Datatilsynet eller en kunde spørger. Jeg er ikke jurist, så hvad der kræves i netop din situation, bør en rådgiver vurdere.

Investering, opkøb og betalinger

Skal du rejse kapital eller sælge virksomheden, kigger investor eller køber ofte på teknikken i en due diligence (en grundig gennemgang før handlen). En nylig pentest med rettede fund viser at sikkerheden er taget alvorligt. En gammel rapport med åbne kritiske fund gør det modsatte.

Kortdata er en kategori for sig. Gemmer eller behandler du selv kortnumre, stiller kortbranchens sikkerhedsstandard PCI DSS krav om regelmæssige penetrationstests. Bruger du en betalingsudbyder med hostet betalingsside hvor kortnummeret aldrig rører din server, ligger det tunge ansvar typisk hos udbyderen.

Hvornår du ikke skal bruge penge på en pentest (endnu)

En pentest er dyr, og den bliver ikke mere værd af at finde ting du selv kunne have rettet. I de her situationer anbefaler jeg typisk noget andet først:

• Frameworket eller pakkerne er flere versioner bagud. Så bruger testerne tid på kendte huller som en opdatering ville have lukket. Start med at opdatere framework og pakker, og tjek om din Laravel-version stadig får sikkerhedsopdateringer.
• Appen er en MVP med få brugere og ingen følsomme data. Brug pengene på et code review og en automatisk scanning, og planlæg testen til når de første store kunder eller følsomme data kommer.
• Ingen vedligeholder koden. En rapport uden en udvikler til at rette fundene er bare en liste over problemer du nu officielt kender til.
• Store dele af systemet skal snart bygges om. Test det system der skal i drift, ikke det der er på vej ud.
• Du forventer et stempel der holder for evigt. En pentest er et øjebliksbillede af én version, og næste opdatering kan åbne nye huller.

Er du i tvivl, er et code review ofte det billigste første skridt. Det viser om koden er klar til en pentest, og hvad der skal rettes inden.

Sådan gør du webappen klar: 7 trin før testen

Testdagene er dyre, så de skal bruges på det svære. Trin 1-4 fjerner det åbenlyse, og trin 5-7 gør testen nem at udføre.

Ret det åbenlyse først

1. Få kravet på skrift. Spørg den der kræver testen: hvad skal testes, hvilken type rapport vil de se, og hvornår skal de bruge den? Så kan testfirmaet give et præcist tilbud, og du betaler ikke for mere end nødvendigt.
2. Opdater framework og pakker. Kør composer audit og npm audit (kommandoer der tjekker dine pakker mod lister over kendte sårbarheder), og ret det de finder.
3. Gennemgå adgangsstyringen. Øverst på OWASP Top 10:2025, den mest brugte liste over sikkerhedsrisici i webapps, står brudt adgangskontrol: at en bruger kan se eller ændre data vedkommende ikke burde have adgang til. Tjek at hver side og hvert API-kald kontrollerer at brugeren må se netop de data, og ikke kun at brugeren er logget ind.
4. Ryd op i konfigurationen. Debug-tilstand, der viser tekniske fejldetaljer til alle, skal være slået fra i drift (i Laravel APP_DEBUG=false), hemmelige nøgler skal ligge uden for koden, login skal have en grænse for antal forsøg, og alt skal køre over HTTPS. Flere af de klassiske huller gennemgår jeg i oversigten over 15 sårbarheder alle webapps skal beskyttes mod.

Gør testen nem at udføre

5. Sæt et testmiljø op. Et staging-miljø (en kopi af systemet til test) med samme kode og opsætning som drift, men med falske data, lader testerne gå hårdt til værks uden at ramme rigtige kunder. Skal produktion testes, så tag en backup før og aftal tidspunktet.
6. Opret testbrugere og beskriv systemet. Testerne skal have mindst to brugere i hver rolle så de kan prøve at se hinandens data. Giv dem en kort beskrivelse af roller, integrationer og API, og skriv hvad der ikke er med i testen.
7. Aftal spillereglerne. Hvem er kontaktperson, hvilke dage må der testes, og hvad sker der hvis testerne finder noget kritisk undervejs? Det sidste vil du have besked om med det samme, ikke i rapporten tre uger senere.

Pris og valg af sikkerhedsfirma

Hvad koster en penetrationstest?

En penetrationstest prissættes næsten altid efter antal testdage, og antallet afhænger af hvor meget der skal testes. En afgrænset test af en mindre webapp med et par brugerroller kan ofte klares på 3-5 testdage. En platform med mange roller, et offentligt API, integrationer og måske en mobilapp kan tage to uger eller mere.

Som groft skøn kan du regne med et beløb fra omkring 25.000 kr. ekskl. moms for en lille, afgrænset test og op til et sekscifret beløb for store platforme. Priserne varierer meget mellem firmaer, så indhent 2-3 tilbud på præcis samme afgrænsning.

Sådan vælger du sikkerhedsfirma

• Uafhængighed. Firmaet har ikke bygget appen og står ikke for driften af den.
• Manuel test. Spørg hvor stor en del af testen der udføres af mennesker. En rapport der mest er output fra en scanner, kan du få langt billigere.
• Eksempelrapport. Bed om en anonymiseret rapport, og tjek at fundene er forklaret til både ledelsen og udvikleren.
• Gentest. Aftal om en ny test af de rettede fund er med i prisen.
• Kompetencer. Certificeringer som CREST for firmaer og OSCP for den enkelte tester er udbredte tegn på faglighed. Spørg også efter referencer fra lignende systemer.

Efter rapporten: sådan håndterer du fundene

Rapporten inddeler typisk fundene efter alvor, fx kritisk, høj, middel og lav, ofte med en CVSS-score (en standardiseret skala fra 0 til 10). Sådan anbefaler jeg at gribe den an:

1. Ret kritiske og høje fund først, og gør det før næste opdatering går i drift.
2. Find årsagen bag fundet. Finder testerne én side uden adgangskontrol, er der sjældent kun én. Gennemgå alle steder der bruger samme mønster.
3. Skriv en automatisk test for hvert fund så fejlen ikke sniger sig ind igen ved næste ændring.
4. Få en gentest af de rettede fund, og gem den opdaterede rapport. Det er den kunder og investorer vil se.
5. Tag stilling til middel og lave fund. Nogle er reelle risici, andre er teoretiske i netop dit system. Skriv ned hvorfor du accepterer en risiko så beslutningen er dokumenteret.

Del ikke hele rapporten frit. Indtil fundene er rettet, er den en opskrift på hvordan dit system kan angribes. Mange testfirmaer kan levere et kort resumé eller en erklæring som du kan sende til kunder i stedet.

Næste skridt: din tjekliste før pentesten

Brug tjeklisten før du bestiller testen. Kan du krydse alle punkter af, får du mest muligt ud af testdagene.

Mangler du en udvikler til at gøre appen klar eller rette fundene, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende webapps. Selve testen bør du stadig købe hos et uafhængigt sikkerhedsfirma.

Ofte stillede spørgsmål

Hvor lang tid tager en penetrationstest fra start til slut?+

Regn med flere uger selvom selve testen kun tager fra nogle dage til et par uger. Planlægning, aftale og testmiljø skal på plads før, og rapporten skrives bagefter. Gode testfirmaer har desuden ofte ventetid. Har du en deadline fra en kunde, så book testen i god tid, og afsæt også tid til rettelser og gentest før du sender resultatet videre.

Hvor ofte skal en webapp penetrationstestes?+

Én gang om året er det mest almindelige udgangspunkt, og det er også det interval mange kunder spørger efter. Derudover bør du teste efter store ændringer i login, brugerroller, betaling eller API fordi det er dér nye huller typisk opstår. Små løbende ændringer kræver ikke en ny test hver gang hvis du har code review og automatiske tests i hverdagen.

Hvad er forskellen på en pentest og et bug bounty-program?+

En pentest er en afgrænset opgave hvor et firma tester i en aftalt periode og leverer en rapport. Et bug bounty-program inviterer eksterne sikkerhedsfolk til løbende at lede efter huller mod en dusør pr. fund. Det passer typisk til større produkter med et sikkerhedsteam der kan håndtere mange henvendelser. For de fleste mindre webapps er en pentest plus en klar kontaktvej for sikkerhedsfejl det rette niveau.

Hvad gør jeg hvis testen finder et hul der allerede kan være udnyttet?+

Behandl det som en mulig sikkerhedshændelse og ikke som en almindelig fejl. Bed udvikleren om at lukke hullet og gennemgå logfilerne for tegn på at det er brugt. Er persondata berørt, og kan du ikke udelukke at uvedkommende har haft adgang, skal du vurdere om bruddet skal anmeldes til Datatilsynet inden for 72 timer. Få juridisk rådgivning hvis du er i tvivl.