OWASP Top 10 er en liste over de ti mest kritiske sikkerhetsrisikoene for webapplikasjoner, utarbeidet av Open Web Application Security Project (OWASP) og har vært en sentral referanse i applikasjonssikkerhet i mer enn to tiår. Listen gir et felles risikospråk for utviklere, sikkerhetsfolk og tekniske ledere som bygger og beskytter programvare. Nå er den oppdaterte versjonen for 2025 her, og den viser tydelig hvordan trusselbildet har utviklet seg siden 2021 da forrige versjon ble presentert.
Kort om hva OWASP Top 10 er og hva som har endret seg
OWASP Top 10 2025 er ute! Endringene er færre enn mange kanskje forventet, men de er tydelige. Fokus har flyttet seg bort fra enkeltstående kodefeil og over mot systemiske problemer i hvordan applikasjoner bygges, konfigureres og driftes.
De mest interessante endringene handler ikke om nye typer angrep, men om hvor feil i realiteten oppstår i moderne applikasjoner. Dataene bak 2025-listen viser det samme bildet som mange sikkerhetsteam allerede ser i praksis; flest alvorlige funn kommer fra tilgangskontroll, feilkonfigurasjon og avhengigheter man ikke har full kontroll på.
OWASP Top 10 oppdateres omtrent hvert tredje til fjerde år, basert på et omfattende datagrunnlag fra faktiske sårbarhetsfunn, bidrag fra sikkerhetsmiljøer og analyse av reelle angrep. Listen er derfor i mindre grad et teoretisk rammeverk og mer et konsentrat av hva som faktisk går igjen i moderne applikasjoner. Endringene mellom hver versjon er som regel inkrementelle, men de gir et tydelig bilde av hvordan risikoområder og angrepsflater forskyver seg over tid.
OWASP Top 10 2025
Den endelige listen over de ti mest kritiske sikkerhetsrisikoene i webapplikasjoner ser slikt ut:
- Broken Access Control
- Security Misconfiguration
- Software Supply Chain Failures
- Cryptographic Failures
- Injection
- Insecure Design
- Authentication Failures
- Software or Data Integrity Failures
- Security Logging and Alerting Failures
- Mishandling of Exceptional Conditions
Sammenlignet med 2021 er strukturen kjent, men flere kategorier har blitt flyttet, slått sammen eller utvidet. Endringene reflekterer hvordan faktiske angrep gjennomføres i dag.
Referanse: https://owasp.org/Top10/2025/0x00_2025-Introduction/
Software Supply Chain Failures
Den mest betydelige endringen i 2025‑utgaven er introduksjonen av Software Supply Chain Failures som egen kategori. Denne erstatter i praksis Vulnerable and Outdated Components fra 2021 og utvider omfanget betraktelig.
Fokuset er ikke lenger kun på sårbare biblioteker. Kategorien dekker hele kjeden rundt programvaren:
- Tredjepartsavhengigheter
- CI og CD‑pipelines
- Pakkehåndtering og distribusjon
- Tillit til eksterne leverandører
- Eksponering av stack traces og intern informasjon
- Applikasjoner som feiler åpent i stedet for sikkert
- Mangelfull håndtering av timeouts, exceptions og edge cases
Angrep mot forsyningskjeden har vist seg å være både skalerbare og effektive. Når kode kompromitteres før den når produksjon, faller mange tradisjonelle sikkerhetskontroller bort. Dette gjenspeiles også tydelig i praksis. Ved gjennomføring av penetrasjonstester dukker denne typen svakheter nesten alltid opp. Ofte ikke som et isolert funn, men som en gjennomgående svakhet i hvordan miljøet er satt opp. Typiske eksempler er ukontrollerte avhengigheter, manglende restriksjoner i build-pipelines og implisitt tillit til tredjepartskomponenter som ingen i realiteten har verifisert. Dette er også et område mange kunder og organisasjoner systematisk undervurderer. Fokuset ligger ofte på egen kode, mens det forutsettes at alt rundt er trygt så lenge det fungerer. I praksis er det nettopp her angrepsflaten har vokst mest de siste årene. Dette med supply chain er tema som NIS og NIS2 stiller krav til i EU lovgivningen.
Mishandling of Exceptional Conditions
Mishandling of Exceptional Conditions er en ny kategori i 2025. Den tar for seg feil som oppstår når applikasjoner havner i tilstander de ikke er designet for å håndtere.
Dette inkluderer blant annet:
- Eksponering av stack traces og intern informasjon
- Applikasjoner som feiler åpent i stedet for sikkert
- Mangelfull håndtering av timeouts, exceptions og edge cases
I distribuerte systemer og API‑baserte arkitekturer kan slike feil få større konsekvenser enn tidligere. Feil i én tjeneste forplanter seg raskt videre.
SSRF er ikke lenger en egen kategori
Server Side Request Forgery hadde en egen plass i OWASP Top 10 2021. I 2025 er den fjernet som separat kategori og slått sammen med Broken Access Control.
Dette reflekterer hvordan SSRF vanligvis oppstår i praksis. Angrepet lykkes fordi applikasjonen ikke begrenser hvilke interne ressurser den får tilgang til. Dette er et tilgangsproblem og ikke et isolert input‑problem.
Security Misconfigurations har rykket opp
Security Misconfiguration har rykket opp til andreplass i 2025. Dette samsvarer godt med funn fra både testing og hendelser.
Feilkonfigurasjoner forekommer i cloud‑miljøer, containere, API‑gateways og autentiseringsløsninger. Ofte skyldes det standardinnstillinger, kopierte oppsett eller manglende oversikt over hva som faktisk er eksponert.
Konfigurasjon håndteres fortsatt manuelt i mange miljøer, selv der resten av utviklingsløpet er automatisert.
I tillegg ser vi en skummel utvikling hvor prosjekter satser på skyløsninger “fordi det er så sikkert”. Det ser ut til at mange prosjektledere tror at man også overlater ansvaret for sikkerhetskonfigureringen til sky-leverandøren, noe de sjeldent gjør. Sky-leverandøren setter opp et standard driftsmiljø som inneholder en del default tiltak, men det er fortsatt kunden som må tune konfigurasjonen til sin spesifikke applikasjon. Noe som er mer krevende når man ikke sitter med infrastrukturen hos seg selv. Argumenter som at “Vi trenger ikke pålogging, fordi applikasjonen er skjult bak en tilfeldig IP-adresse bare vi og sky-leverandøren kjenner til” er faktisk blitt brukt. Da har man åpnet systemet for alle som tilfeldigvis ping’er IP-adresser, og det er ikke god sikkerhet.
Injection og Cryptographic Failures
Injection og Cryptographic Failures er fortsatt med på OWASP-listen, men har fått mindre vekt enn tidligere.
Dette indikerer økt modenhet i bruken av rammeverk og biblioteker. Klassiske feil er vanskeligere å gjøre, men de forsvinner ikke helt. Når de oppstår i dag, er de ofte knyttet til legacy‑kode eller spesialtilfeller der standardmekanismer omgås. For Cryptographic Failures ser man dette særlig rundt TLS‑oppsett og nøkkelhåndtering. Svake eller utdaterte TLS‑konfigurasjoner, feil sertifikatvalidering og gjenbruk av nøkler er gjengangere i testing. Ofte er selve kryptografien i seg selv korrekt, men brukt feil i kontekst. For eksempel når TLS termineres feil, intern trafikk forutsettes som betrodd, eller egenimplementerte løsninger introduseres der etablerte mekanismer allerede finnes.
Det er også mange som fortsatt tillater kommunikasjon på TLS v 1.2 eller lavere siden mange eldre systemer ikke er oppgradert. Dette gir en Bakover kompabilitet ja, men vær klar over at i dag er sikkerhetskravet TLS v1.2 eller høyere. Man bør heller sette krav til at de gamle systemene oppdateres til en sikker versjon enn å redusere sikkerheten i den nye applikasjonen.
Hva listen sier om dagens applikasjoner
OWASP Top 10 2025 peker tydelig mot grunnleggende kontrollproblemer:
- Manglende eller feil tilgangskontroll
- Utilstrekkelig kontroll på konfigurasjon
- Uklar tillit til kode og komponenter
Disse problemene løses ikke med enkeltpatcher. De krever tydelig struktur, klart eierskap og kontinuerlig oppfølging gjennom hele livssyklusen til applikasjonen. I praksis betyr det at sikkerhet må være forankret i etablerte rammeverk og styringsprinsipper, ikke overlatt til enkeltpersoner eller ad hoc-tiltak. Det viser også at sikkerhet må inn i design-fasen og er ikke noe som kan legges til når prosjektet avsluttes. Da vil ofte kostnadene med å programmere om løsningen og skifte ut usikre komponenter i infrastrukturen drepe systemet før det kan tas i bruk. Begrepet “Security by Design, Security by Default” er viktig å bringe med seg når man starter utviklingen av en ny løsning.
Når det gjelder tilgangskontroll ser vi at stadig flere bruker Multifaktor autentisering (MFA) på absolutt alle sine systemer i sky-løsninger. Det er i og for seg flott, men da skiller man ikke lenger på lav-risiko og høy-risiko systemer når det gjelder tilgang. Og god sikkerhetstenking er at man skal ha ekstra lag av sikkerhet mellom de forskjellige klassene. Man bør da enten gjøre en ny tilgangs-autorisering med andre MFA-faktorer for å nå høy-risiko systemer eller benytte Secure Single Sign-on løsning for den ene klassen som et ekstra lag. Da vil bare brukere definert i en egen sikkerhetsgruppe ha tilgang til høy-risiko systemer.
For nordiske virksomheter finnes det etablerte rammeverk som gir et godt utgangspunkt for dette arbeidet. I Norge er NSMs grunnprinsipper for IKT-sikkerhet mye brukt, mens tilsvarende prinsipper finnes hos blant annet MSB i Sverige. Felles for disse er fokus på styring og kontroll, beskyttelse av systemer og data, samt evne til å oppdage og håndtere hendelser. Når slike rammeverk brukes aktivt i utvikling og drift, gir de en struktur som støtter mange av risikoområdene OWASP Top 10 peker på.
Dette innebærer blant annet definerte sikkerhetskrav i designfasen, tydelig ansvar for tilgangsstyring og konfigurasjon, samt kontinuerlig verifikasjon gjennom testing og overvåkning. Uten denne typen struktur vil de samme funnene fortsette å dukke opp, uavhengig av hvor mange sårbarheter som patches underveis.
OWASP Top 10 2025 peker ikke på nye problemer. Den dokumenterer at de samme grunnleggende svakhetene fortsatt finnes i moderne applikasjoner, også i miljøer som oppfattes som teknisk modne. Årsaken ligger sjelden i valg av teknologi, men i hvordan sikkerhet faktisk blir fulgt opp i praksis over tid.
Virksomheter som har struktur, eierskap og kontinuerlig oppfølging reduserer risiko systematisk. De som ikke har det, vil fortsette å avdekke de samme funnene år etter år, uavhengig av skyplattform, rammeverk eller utviklingsmetodikk. OWASP Top 10 fungerer derfor i mindre grad som en varsel-liste og mer som et modenhetsspeil.
Så hva bør prioriteres?
Basert på 2025-listen gir tre tiltak de største effektene:
- Tilgangskontroll må designes, dokumenteres og testes eksplisitt
- Konfigurasjon må automatiseres og verifiseres kontinuerlig
- Supply chain-risiko må håndteres som en del av normal utvikling
OWASP Top 10 2025 viser et kjent bilde og samsvarer godt med det som faktisk avdekkes i testing og hendelseshåndtering. De største sikkerhetsproblemene handler fortsatt om det grunnleggende.
