OWASP: Så skyddar du webbapplikationer i praktiken

Vad är OWASP – och varför spelar det roll?

OWASP är en ideell, community-driven organisation som sedan 2001 tillhandahåller fritt tillgängliga resurser för applikationssäkerhet. Grundad av Mark Curphey, har organisationen vuxit till ett globalt nätverk av tusentals säkerhetsexperter som frivilligt bidrar med verktyg, dokumentation och ramverk.

2023 bytte organisationen namn från "Open Web Application Security Project" till "Open Worldwide Application Security Project" – en signal om att deras arbete sedan länge spänner över mer än bara webbapplikationer. IoT, mobilappar, API:er och maskininlärningsmodeller ingår numera i deras scope.

Varför detta spelar roll för svenska organisationer: Med NIS2-direktivet och GDPR:s krav på tekniska och organisatoriska skyddsåtgärder behöver ni kunna visa att säkerhetsarbetet vilar på erkända standarder. OWASP fyller den rollen – Integritetsskyddsmyndigheten (IMY) och revisorer förstår referensen. Det är inte en certifiering, men det är en trovärdig grund att bygga säkerhetsarbetet på.

Från Opsios SOC i Karlstad ser vi dagligen attacktrafik mot webbapplikationer som direkt mappas till OWASP Top 10-kategorierna. Det handlar inte om teoretiska risker – det är precis vad hotaktörer faktiskt utnyttjar.

OWASP Top 10: De vanligaste sårbarheterna

OWASP Top 10 (senast uppdaterad 2021) är den mest refererade listan inom applikationssäkerhet. Den baseras på dataanalys av hundratusentals applikationer och bygger konsensus bland säkerhetsexperter globalt. Här är listan med våra operativa kommentarer:

A01: Broken Access Control – det vi ser oftast

Broken Access Control klättrade till förstaplatsen 2021, och det stämmer väl med vad vi hanterar i Opsios SOC. Typiska fall:

• Horisontell eskalering: Användare A ändrar ett ID i URL:en och får tillgång till Användare B:s data
• Vertikal eskalering: Vanliga användare som når admin-funktioner genom att manipulera API-anrop
• CORS-felkonfiguration: Webbapplikationer som accepterar requests från godtyckliga origins

Åtgärden är inte komplicerad men kräver disciplin: implementera åtkomstkontroll server-side, validera varje request mot användarens faktiska behörigheter, och testa med automatiserade verktyg i CI/CD. Deny-by-default bör vara grundprincipen.

A03: Injection – inte bara SQL längre

SQL Injection har fått mycket uppmärksamhet, och tack vare parametriserade queries och ORM-ramverk är det vanligare att vi ser andra typer av injection i moderna applikationer:

• NoSQL Injection i MongoDB-baserade applikationer
• LDAP Injection mot företagskataloger
• Template Injection i server-side rendering (Jinja2, Freemarker)
• OS Command Injection via dåligt validerad input till systemanrop

Principen är densamma: lita aldrig på indata. Validera, sanitera och använd parametriserade interfaces genomgående.

OWASP:s verktyg i praktiken

OWASP erbjuder inte bara listor – de producerar verktyg som är fullt användbara i produktion. Här är de vi faktiskt rekommenderar och använder:

ZAP (Zed Attack Proxy)

OWASP ZAP är det mest använda öppna DAST-verktyget (Dynamic Application Security Testing). Det fungerar som en intercepting proxy som identifierar sårbarheter i körande webbapplikationer.

Så använder vi ZAP i kundprojekt:

• Automatiserade skanningar som del av CI/CD-pipelines (GitHub Actions, GitLab CI)
• Baseline-skanningar vid varje deploy till staging-miljö
• Full-skanningar veckovis mot produktionsmiljöer (med kundens medgivande)
• API-skanningar mot OpenAPI/Swagger-specifikationer

ZAP ersätter inte manuell penetrationstestning, men fångar en stor andel av de vanligaste sårbarheterna automatiskt.

Dependency-Check

OWASP Dependency-Check analyserar projektberoenden mot kända sårbarheter i NVD (National Vulnerability Database). Det är SCA (Software Composition Analysis) i sin enklaste och mest effektiva form.

```bash

Exempel: Maven-integration

mvn org.owasp:dependency-check-maven:check

```

Vi konfigurerar Dependency-Check med en CVSS-tröskel – bygget misslyckas om en sårbarhet med CVSS ≥ 7.0 hittas. Det tvingar teamet att hantera sårbarheter omedelbart istället för att skjuta upp dem.

OWASP SAMM (Software Assurance Maturity Model)

SAMM är ett mognadsramverk som hjälper organisationer att mäta och förbättra sitt säkerhetsarbete systematiskt. Det organiseras i fem affärsfunktioner: Governance, Design, Implementation, Verification och Operations.

Vi använder SAMM-bedömningar som startpunkt när nya kunder vill förstå var de befinner sig och vart de bör prioritera. Det ger ett gemensamt språk mellan utvecklare, drift och ledning – vilket ofta är den största utmaningen i säkerhetsarbete.

Implementera OWASP i er utvecklingsprocess

Att känna till OWASP Top 10 är steg ett. Att faktiskt integrera principerna i den dagliga utvecklingsprocessen är där det verkliga värdet uppstår.

Shift-left: Säkerhet från första kodraden

Konceptet "shift-left" innebär att flytta säkerhetsarbetet så tidigt som möjligt i utvecklingslivscykeln. I praktiken:

1. Hotmodellering vid design – Använd OWASP Threat Dragon eller STRIDE-metodik innan en enda rad kod skrivs

2. SAST i IDE:n – Verktyg som SonarLint flaggar sårbarheter medan utvecklaren skriver kod

3. Pre-commit hooks – Secrets-scanning (med verktyg som gitleaks) innan känslig information ens hamnar i versionshantering

4. Automatiserade säkerhetstest i CI/CD – ZAP, Dependency-Check, licensgranskning

5. Säkerhetsgranskning i code review – Definierade checklistor baserade på OWASP ASVS

OWASP ASVS som verifieringsramverk

ASVS (Application Security Verification Standard) erbjuder tre verifieringsnivåer:

Vår rekommendation: Börja med ASVS L1 som baseline för alla applikationer. Kartlägg vilka applikationer som hanterar personuppgifter (GDPR-relevanta) och lyft dem till L2. Reservera L3 för system som faller under NIS2-direktivets krav på väsentliga och viktiga entiteter.

Molnsäkerhet för svenska organisationer

OWASP och molnsäkerhet

Molnmiljöer har egna säkerhetsutmaningar som delvis överlappar med OWASP Top 10 men också introducerar nya dimensioner.

SSRF i molnmiljöer – ett konkret hot

A10 (Server-Side Request Forgery) blev ett topptio-problem delvis på grund av molnens metadatatjänster. I AWS kan en SSRF-sårbarhet ge angriparen tillgång till Instance Metadata Service (IMDS) på 169.254.169.254, vilket potentiellt exponerar temporära IAM-credentials.

Åtgärder vi implementerar:

• IMDSv2 (kräver sessionstoken) på alla EC2-instanser
• Nätverkssegmentering med VPC-konfiguration som begränsar metadataåtkomst
• WAF-regler som blockerar requests mot interna IP-adresser
• Managed identities/roles istället för hårdkodade credentials

Security Misconfiguration i moln

A05 (Security Misconfiguration) är särskilt relevant i molnmiljöer. Flexeras State of the Cloud-rapporter har konsekvent visat att säkerhet och governance är bland de högst rankade utmaningarna för molnanvändare. Det vi ser dagligen:

• IAM-policies som är för breda – :-permissions som ger full åtkomst
• Publikt exponerade lagringsbuckets – S3, Azure Blob Storage, GCS
• Säkerhetsgrupper med 0.0.0.0/0 på känsliga portar
• Avsaknad av kryptering för data at rest

Infrastructure as Code (IaC) med verktyg som Terraform, kombinerat med policykontroller som OPA (Open Policy Agent) eller AWS Config Rules, fångar dessa felkonfigurationer innan de når produktion.

Managerade molntjänster med säkerhet inbyggd

OWASP, NIS2 och svensk efterlevnad

Med NIS2-direktivet som träder i kraft i svensk lagstiftning ställs högre krav på riskhantering och incidentrapportering för väsentliga och viktiga entiteter. OWASP-ramverket ger praktiskt stöd:

• OWASP SAMM → Dokumenterar er säkerhetsmognad (NIS2 kräver riskbaserad approach)
• OWASP Top 10 → Visar att ni adresserar kända, relevanta hot
• OWASP ASVS → Ger verifierbara säkerhetskrav (revision och tillsyn)
• OWASP Testing Guide → Systematisk testmetodik som kan dokumenteras

GDPR artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder". Att följa OWASP ASVS L2 för system som behandlar personuppgifter är ett starkt argument vid tillsyn från IMY.

Praktiskt tips: Dokumentera era OWASP-baserade säkerhetsåtgärder i ett Security Assurance Framework som kan presenteras vid revision. Koppla varje åtgärd till specifika OWASP-krav och NIS2-artiklar.

Efterlevnad och governance i molnet

Vanliga misstag – och hur ni undviker dem

Baserat på vad vi ser hos organisationer som tar sina första steg med OWASP:

Misstag 1: Behandla OWASP Top 10 som en checklista att bocka av

Top 10 är ett medvetandehöjande dokument, inte en komplett säkerhetsstandard. Använd ASVS för systematisk verifiering.

Misstag 2: Köra ZAP-skanningar men aldrig agera på resultaten

Verktyg som producerar rapporter ingen läser är slöseri. Integrera ZAP i CI/CD och låt bygget misslyckas vid högrisk-fynd.

Misstag 3: Fokusera på verktygen och glömma processerna

OWASP SAMM poängterar att verktyg bara är en del av bilden. Utbildning, hotmodellering och governance är minst lika viktiga.

Misstag 4: Anta att OWASP-åtgärder räcker för allt

OWASP täcker applikationssäkerhet. Ni behöver fortfarande nätverkssäkerhet, endpoint-skydd, identitetshantering och fysisk säkerhet. Säkerhet är lager på lager.

Managerad DevOps med inbyggd säkerhet

Så kommer ni igång – en pragmatisk plan

Istället för att försöka implementera allt på en gång rekommenderar vi denna sekvens:

Vecka 1–2: Kör en OWASP SAMM-bedömning. Förstå var ni står.

Vecka 3–4: Integrera Dependency-Check i era CI/CD-pipelines. Omedelbart värde, låg ansträngning.

Månad 2: Sätt upp automatiserade ZAP baseline-skanningar mot staging-miljöer.

Månad 3: Börja med hotmodellering för nya funktioner. Använd OWASP Threat Dragon.

Månad 4–6: Implementera ASVS L1-krav som del av era acceptanskriterier för kod.

Löpande: Säkerhetsutbildning baserad på OWASP Top 10 för alla utvecklare, minst kvartalsvis.

Det här är inte ett engångsprojekt. Hotbilden förändras, applikationer utvecklas, och nya sårbarheter upptäcks kontinuerligt. Opsios SOC/NOC-team ser detta dygnet runt – säkerhet är en process, inte ett tillstånd.

Cloud FinOps – optimera kostnaden för säkerhet

Vanliga frågor

Vad är skillnaden mellan OWASP Top 10 och OWASP ASVS?

Top 10 är en prioriterad lista över de vanligaste sårbarheterna – ett bra startläge för medvetenhet. ASVS (Application Security Verification Standard) är ett detaljerat verifieringsramverk med tre nivåer av krav, avsett för systematisk säkerhetstestning. Använd Top 10 för att kommunicera risker, ASVS för att verifiera att ni faktiskt åtgärdat dem.

Är OWASP bara relevant för webbutveckling?

Nej. Sedan namnbytet 2023 till "Open Worldwide Application Security Project" täcker OWASP även mobilapplikationer (OWASP Mobile Top 10), API:er (OWASP API Security Top 10), IoT och maskininlärningsmodeller (OWASP ML Top 10). Principerna är applikationsagnostiska.

Hur ofta uppdateras OWASP Top 10?

Historiskt vart tredje till fjärde år – senaste versionen publicerades 2021. Uppdateringarna baseras på dataanalys av hundratusentals applikationer och input från säkerhetsexperter globalt. Mellan uppdateringar publicerar OWASP kontinuerligt nya resurser och verktyg.

Kan OWASP-verktyg ersätta kommersiella säkerhetslösningar?

OWASP:s verktyg som ZAP ger solid grundtäckning, särskilt för DAST. Men för större organisationer kompletterar de snarare än ersätter kommersiella SAST/DAST-plattformar. Vi rekommenderar en lagerbaserad strategi där OWASP-verktyg i CI/CD-pipelines fångar lågt hängande frukt och kommersiella verktyg ger djupare analys.

Hur hänger OWASP ihop med NIS2 och GDPR?

NIS2-direktivet kräver riskbaserad säkerhet och incidenthantering – OWASP:s ramverk ger konkreta metoder för att uppfylla dessa krav. GDPR artikel 25 och 32 kräver "security by design" och "lämpliga tekniska åtgärder", där OWASP ASVS och SAMM fungerar som dokumenterbar praxis vid tillsyn från IMY.