SoftwareudviklingTjekliste
enRead in EnglishWebsikkerhed: 15 sårbarheder alle webapps skal beskyttes mod
Websikkerhed i webapps: 15 sårbarheder fra OWASP Top 10 forklaret som forretningsrisiko, med det spørgsmål du bør stille din udvikler om hver.
Freelance full-stack udvikler
- Udgivet
- Læsetid
- 8 min.
Indhold i indlægget8
Websikkerhed i en webapp handler for det meste om de samme 15 huller: brugere der kan se andres data, login der kan gættes, forældede pakker, nøgler i koden og fejl som ingen opdager. Tjeklisten herunder bygger på OWASP Top 10 fra 2025 og oversætter hver sårbarhed til hvad den kan koste dig, og hvilket spørgsmål du kan stille din udvikler.
Jeg tilbyder selv vedligehold og sikkerhedsopdateringer af webapps, så læs mine råd om hvornår du skal have hjælp med det forbehold.
Den korte version: OWASP Top 10 på almindeligt dansk
OWASP Top 10 fra 2025 er den mest brugte liste over sikkerhedsrisici i webapps. Her er de ti kategorier oversat til hvad de betyder for dig, og hvilke af de 15 punkter i tjeklisten der hører til.
| OWASP 2025 | Hvad det betyder for dig | Punkt |
|---|---|---|
| A01 Broken Access Control | Brugere kan se eller gøre mere end de må | 1-3 |
| A02 Security Misconfiguration | Server eller app er sat forkert op | 5 |
| A03 Software Supply Chain Failures | Pakker og værktøjer med kendte huller | 7 |
| A04 Cryptographic Failures | Adgangskoder og data er dårligt beskyttet | 8 |
| A05 Injection | Input fra brugere bliver kørt som kode | 9-10 |
| A06 Insecure Design | Forretningslogikken kan snydes | 11-12 |
| A07 Authentication Failures | Login kan gættes, omgås eller lækkes | 4, 6 |
| A08 Software or Data Integrity Failures | Appen stoler på data den ikke har tjekket | 13 |
| A09 Security Logging and Alerting Failures | Ingen opdager når noget går galt | 15 |
| A10 Mishandling of Exceptional Conditions | Fejl der lækker information eller åbner op | 14 |
Har du kun tid til fem punkter, så start med 1, 2, 4, 5 og 7. Efter min vurdering er det dem der rammer flest apps. Sikkerhed hører til i hele forløbet fra idé til drift, så brug tjeklisten løbende og ikke kun før lancering.
Adgang og login: hvem må hvad (punkt 1-4)
Fejl i adgangskontrol er svære at se, fordi alt virker normalt for den der bruger appen som tiltænkt.
Adgang og login
- 1. Andres data ligger et ID væk: Kan en kunde se en andens faktura ved at ændre /faktura/1041 til /faktura/1042, har du et databrud. Spørg: "Tjekker serveren ejerskab på hver forespørgsel, og er det dækket af automatiske tests?"
- 2. Rettigheder kun i brugerfladen: En skjult admin-knap beskytter ikke funktionen bag den. En almindelig bruger kan kalde den direkte og fx ændre priser. Spørg: "Hvor i koden håndhæves roller, og kan en bruger selv ændre sin rolle?"
- 3. Forfalskede forespørgsler (CSRF): En ondsindet side får en indlogget brugers browser til at sende en formular til din app, fx med en ny e-mailadresse. Spørg: "Har alle formularer og kald der ændrer data, CSRF-beskyttelse?"
- 4. Login der kan gættes eller omgås: Uden grænse for loginforsøg kan bots afprøve lækkede adgangskoder fra andre sider. Spørg: "Har vi begrænsning på loginforsøg, to-faktor for administratorer og nulstillingslinks der udløber?"
Et godt svar på punkt 1 og 2 lyder fx: "Alle ruter har rettighedstjek på serveren, og vi har tests der prøver at hente en anden brugers data." Svaret "det har vi aldrig haft problemer med" betyder typisk at ingen har tjekket.
Opsætning, nøgler og pakker (punkt 5-8)
Automatiske scannere leder hele tiden efter de her fejl, så ingen virksomhed er for lille til at blive ramt.
Opsætning, nøgler og pakker
- 5. Fejlkonfiguration i produktion: Debug-tilstand slået til, standardlogins, åbne adminpaneler eller manglende HTTPS. Laravel skriver selv i dokumentationen om debug-tilstand at du risikerer at vise følsomme konfigurationsværdier til brugerne. Spørg: "Hvordan sikrer vi at produktion er sat op anderledes end udviklingsmiljøet?"
- 6. Hemmelige nøgler i koden: Nøgler til betaling, mail eller AI i koden, i Git-historikken eller i browseren kan misbruges på din regning. Spørg: "Hvor ligger vores nøgler, hvem har adgang, og hvornår blev de sidst skiftet?"
- 7. Forældede pakker: Når en sårbarhed i en pakke bliver offentliggjort, kan alle læse sig til hvordan den udnyttes. Spørg: "Hvordan får vi besked om sikkerhedsopdateringer, og hvor hurtigt bliver de installeret?"
- 8. Adgangskoder og data gemt forkert: Adgangskoder skal hashes med en moderne algoritme som bcrypt eller Argon2 og må aldrig ligge i klartekst. Følsomme felter og backups bør krypteres. Spørg: "Hvordan gemmes adgangskoder, og er vores backups krypteret?"
Punkt 7 er det der lettest glider, når appen bare kører. Se hvad det koster at lade framework og pakker sakke bagud.
Input fra brugere: injection, scripts og filer (punkt 9-12)
Alt hvad en bruger sender til din app, skal behandles som potentielt ondsindet. Moderne frameworks beskytter mod meget af det fra start, og det er en af grundene til at Laravel er mit standardvalg. Men beskyttelsen virker kun, hvis koden bruger den.
Input og forretningslogik
- 9. SQL-injection: Input bliver sat direkte ind i en databaseforespørgsel, så et søgefelt kan bruges til at læse eller slette databasen. Spørg: "Bruger vi parametriserede forespørgsler overalt, også der hvor vi skriver SQL selv?"
- 10. Cross-site scripting (XSS): Tekst fra én bruger bliver kørt som kode i en andens browser, fx via en kommentar. Rammer det en administrator, kan angriberen overtage kontoen. Spørg: "Bliver alt brugerindhold escapet, når det vises, og hvor har vi bevidst slået det fra?"
- 11. Filuploads uden grænser: Uden tjek af filtype og størrelse kan nogen uploade kode der kører på serveren, eller fylde disken. Private dokumenter må ikke ligge på et offentligt link. Spørg: "Hvilke filtyper accepterer vi, og hvordan beskytter vi private filer?"
- 12. Forretningslogik der kan snydes: Priser der sendes fra browseren, rabatkoder der kan bruges igen og igen, eller ingen grænse for dyre handlinger som SMS og AI-kald. Spørg: "Hvad sker der, hvis nogen kalder vores API direkte 1.000 gange i minuttet?"
Intet værktøj finder hullerne i punkt 12 for dig. OWASP's eksempel under usikkert design er en biografkæde, hvor en angriber kunne booke 600 pladser med få forespørgsler. Der manglede bare en regel for hvor meget én person må booke.
Integrationer, fejl og overvågning (punkt 13-15)
Integrationer, fejl og overvågning
- 13. Data og kode der ikke bliver tjekket: Et webhook fra betalingsudbyderen skal have verificeret signatur, ellers kan alle markere en ordre som betalt. Det samme gælder eksterne scripts og adgangen til at udgive ny kode. Spørg: "Verificerer vi signaturen på alle webhooks, og hvem kan udgive ny kode?"
- 14. Fejl der lækker eller åbner op: Detaljerede fejlbeskeder viser angribere hvordan systemet er bygget. Værre er kode der "fejler åbent" og fx godkender en ordre, når betalingstjekket ikke svarer. Spørg: "Hvad ser brugeren, når noget går galt, og afviser vi som udgangspunkt, når et tjek fejler?"
- 15. Ingen logning eller alarmer: Uden logs opdager du først et brud, når en kunde ringer, og du kan ikke se hvilke data der er berørt. Spørg: "Hvad logger vi, hvor længe gemmes det, og hvem får en alarm?"
Logning har også en juridisk side: et brud på persondatasikkerheden skal som udgangspunkt anmeldes til Datatilsynet uden unødig forsinkelse og så vidt muligt inden for 72 timer. Det kræver at du kan se hvad der er sket.
Hvornår tjeklisten er for meget, og hvornår den ikke er nok
Har du en hjemmeside uden login, betaling eller følsomme data, er de fleste punkter ikke relevante. Hold systemet opdateret, slå to-faktor til for administratorer, og hav en backup du har prøvet at gendanne. Brug ikke penge på en stor gennemgang.
Behandler appen helbredsoplysninger, eller kræver dine kunder dokumentation for sikkerheden, så køb en penetrationstest hos et firma der kun laver sikkerhed. Jeg er udvikler, ikke penetrationstester. Min rolle er at bygge og vedligeholde koden, så hullerne ikke opstår, og lukke dem en test finder.
Får du vage svar på mange af spørgsmålene, er problemet sjældent kun sikkerhed. Se på tegnene på om kodebasen er sund. Sikkerhedshuller er ofte den del af den tekniske gæld, der forfalder først.
Næste skridt
- Send de 15 spørgsmål til din udvikler eller leverandør, og bed om skriftlige svar.
- Start med de punkter hvor svaret er vagt eller mangler.
- Aftal fast vedligehold med sikkerhedsopdateringer, så tjeklisten ikke bliver en engangsøvelse.
Har du ingen der holder øje med din app i dag, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af webapps. Du taler direkte med den udvikler der skriver koden.
Ofte stillede spørgsmål
Hvor ofte skal en webapp have et sikkerhedstjek?
Løbende. Jeg anbefaler automatisk besked om sårbare pakker hver uge, et tjek af rettigheder ved hver større ny funktion og en gennemgang af hele tjeklisten mindst årligt. Med følsomme data eller mange brugere bør du også købe en ekstern penetrationstest, fx før lancering og derefter årligt.
Hvad er forskellen på en sikkerhedsgennemgang og en penetrationstest?
En sikkerhedsgennemgang ser på kode og opsætning indefra, typisk af en udvikler med fuld adgang. En penetrationstest angriber appen udefra og laves af specialister. Gennemgangen finder flest fejl i logik og opsætning, og testen viser om de kan udnyttes. Mange apps har brug for den første, før den anden er pengene værd.
Hvem har ansvaret, hvis vores webapp bliver hacket?
Som udgangspunkt har din virksomhed ansvaret over for kunderne, fordi I er dataansvarlige for de persondata appen behandler. GDPR kræver et passende sikkerhedsniveau, også selvom en ekstern udvikler har bygget appen. Hvad du kan kræve af udvikleren, afhænger af jeres kontrakt og databehandleraftale. Tal med en juridisk rådgiver om din konkrete situation.