OWASP Top 10: Det du faktiskt behöver veta

OWASPs Top 10 (senaste versionen från 2021) är inte en heltäckande lista över alla tänkbara angrepp. Det är en riskrankning baserad på faktiska data från hundratals organisationer. Här är de kategorier som kräver mest uppmärksamhet för svenska verksamheter, med Opsios driftsperspektiv:

A01: Broken Access Control – den vanligaste bristen

Bristande åtkomstkontroll toppar listan. Det handlar om att användare kan nå data eller funktioner de inte ska ha tillgång till – exempelvis att ändra ett ID-nummer i URL:en för att se någon annans orderhistorik (IDOR), eller att en vanlig användare kan anropa admin-API:er.

Vad vi ser i praktiken: Utvecklare bygger ofta åtkomstkontroll i frontend men glömmer att validera i backend. Det räcker att öppna webbläsarens utvecklarverktyg för att kringgå skyddet.

Åtgärd: Implementera åtkomstkontroll på serversidan, använd principen om minsta möjliga behörighet (least privilege) och testa med automatiserade verktyg som testar horisontell och vertikal eskalering.

A03: Injection – SQL-injektion och dess släktingar

SQL-injektion är en klassiker som fortfarande dyker upp. Angripare matar in skadlig kod i indatafält som tolkas som databaskommandon. Samma princip gäller för LDAP-injektion, OS Command Injection och nyare varianter som NoSQL-injektion.

Åtgärd: Parametriserade frågor (prepared statements) eliminerar SQL-injektion i princip helt. Det finns ingen ursäkt att inte använda dem 2026. Komplettera med input-validering och WAF-regler som fångar uppenbara injektionsförsök.

A07: Cross-Site Scripting (XSS)

XSS tillåter angripare att injicera JavaScript-kod som körs i andra användares webbläsare. Det kan leda till sessionsstöld, phishing och defacement. Trots att moderna ramverk som React och Vue erbjuder inbyggt skydd mot XSS ser vi fortfarande sårbarheter – ofta i äldre koddelar eller där utvecklare medvetet kringgår ramverkets skydd med dangerouslySetInnerHTML eller liknande.

Åtgärd: Kontextuell output-encoding, Content Security Policy (CSP) och regelbunden DAST-skanning.

Regulatoriska krav i Sverige: GDPR, NIS2 och IMY

GDPR – artikel 32 och verkligheten

GDPR kräver "lämpliga tekniska och organisatoriska åtgärder" för att skydda personuppgifter (artikel 32). Vad som är "lämpligt" beror på risknivån, men Integritetsskyddsmyndigheten (IMY) har genom sina tillsynsbeslut visat att otillräcklig applikationssäkerhet – som avsaknad av kryptering, bristfällig autentisering eller öppna API:er – anses vara en överträdelse.

IMY har utfärdat sanktioner på tiotals miljoner kronor mot svenska organisationer de senaste åren, och tillsynsaktiviteten har ökat markant sedan NIS2-arbetet intensifierades.

NIS2 – nya krav med tänder

NIS2-direktivet, som implementeras i svensk lag, utökar kretsen av organisationer som måste bedriva systematiskt informationssäkerhetsarbete. Direktivet ställer bland annat krav på:

• Riskanalys och säkerhetspolicyer för informationssystem
• Incidenthantering med rapportering inom 24 timmar till CERT-SE
• Kontinuitetsplanering och krishantering
• Leveranskedjesäkerhet – du ansvarar för dina underleverantörers säkerhet
• Ledningens ansvar – personligt ansvar för att säkerhetsarbetet bedrivs

För webbapplikationer innebär detta att organisationer behöver dokumenterad säkerhetsarkitektur, regelbundna penetrationstester och incidentresponsplaner som faktiskt testats.

Molnmigrering

Shift-left: Bygg in säkerhet i CI/CD-pipelinen

Den dyraste buggen är den som hittas i produktion. Den billigaste är den som utvecklaren ser i sin editor innan koden ens committats. Det är kärnan i shift-left-filosofin.

Praktisk implementation

En mogen säkerhetspipeline ser ut ungefär så här:

1. Pre-commit: Secrets-skanning (GitLeaks, TruffleHog) och linting för säkerhetsregler

2. Build: SAST-analys (Semgrep, SonarQube, Checkmarx) som bryter bygget vid kritiska fynd

3. Beroendeanalys: SCA-verktyg (Snyk, Dependabot, Trivy) som flaggar kända sårbarheter i tredjepartsberoenden

4. Staging: DAST-skanning (OWASP ZAP, Burp Suite) mot en deployad testmiljö

5. Release gate: Inga kritiska eller höga sårbarheter passerar utan explicit godkännande från säkerhetsteamet

6. Produktion: Runtime-skydd, WAF och SOC-övervakning

```yaml

Exempel: GitHub Actions säkerhetssteg

• name: SAST - Semgrep

uses: returntocorp/semgrep-action@v1

with:

config: p/owasp-top-ten

• name: SCA - Trivy

uses: aquasecurity/trivy-action@master

with:

scan-type: 'fs'

severity: 'CRITICAL,HIGH'

exit-code: '1'

```

Nyckeln är att dessa steg inte upplevs som bromsklossar av utvecklarna. Snabba skanningar (under 2 minuter), tydlig feedback och låg andel falsklarm är avgörande för att teamet faktiskt följer processen istället för att kringgå den.

Managerad DevOps

WAF och molnbaserat skydd: Hygienfaktorer

En Web Application Firewall (WAF) inspekterar HTTP-trafik och blockerar kända attackmönster. De tre stora molnleverantörerna erbjuder alla inbyggda WAF-lösningar:

En WAF är dock bara ett lager. I Opsios SOC ser vi regelbundet att organisationer förlitar sig enbart på WAF-skydd och missar att:

• WAF:en inte skyddar mot logikfel (exempelvis att en användare kan beställa varor till negativt pris)
• Reglerna behöver underhållas och anpassas löpande
• Bot-trafik som inte matchar kända attackmönster passerar obemärkt
• API:er som inte går genom WAF:en lämnas oskyddade

Komplettera alltid med rate limiting, bot-hantering (exempelvis reCAPTCHA Enterprise eller AWS WAF Bot Control) och API-gateway med autentisering.

Managerade molntjänster

Autentisering och åtkomstkontroll som faktiskt håller

Autentisering (vem är du?) och auktorisering (vad får du göra?) är fundamentet. Brister här öppnar dörren oavsett hur bra resten av säkerheten är.

Modern autentisering 2026

• Lösenordslös autentisering (passkeys/FIDO2) bör vara standardval för nya applikationer. Apple, Google och Microsoft stödjer alla passkeys, och användaracceptansen ökar snabbt.
• MFA är inte förhandlingsbart för interna system och administrativa gränssnitt. SMS-baserad MFA är bättre än inget men sårbart för SIM-swapping – välj TOTP eller FIDO2.
• Centraliserad identitetshantering via en IdP (Identity Provider) som Azure AD/Entra ID, Okta eller AWS IAM Identity Center. Undvik att bygga egen autentiseringslogik.

Auktorisering i praktiken

• Implementera RBAC (rollbaserad åtkomstkontroll) eller ABAC (attributbaserad) beroende på komplexiteten
• Validera alltid på serversidan – frontend-kontroller är kosmetiska
• Logga alla åtkomstförsök och sätt upp larm på avvikande mönster
• Granska behörigheter kvartalsvis – "privilege creep" är en av de vanligaste driftssårbarheterna vi ser

Incidentrespons: Förberedelse avgör utfallet

En säkerhetsincident i en webbapplikation – vare sig det är ett dataintrång, en DDoS-attack eller en komprometterad tredjepartskomponent – kräver snabb och samordnad respons. Skillnaden mellan organisationer som återhämtar sig på timmar och de som kämpar i veckor är nästan alltid förberedelse.

Opsios rekommenderade playbook-struktur

1. Detektion: Centraliserad loggning (ELK, Datadog, AWS CloudTrail) → SIEM-korrelering → SOC-larm

2. Triage: Bedöm allvarlighetsgrad, påverkade system och datakategorier (personuppgifter = GDPR-rapportering)

3. Inneslutning: Isolera påverkat system utan att förstöra bevisning. Automatiserade runbooks i t.ex. AWS Systems Manager sparar kritiska minuter.

4. Utredning: Fastställ rotorsak, angreppsvektor och omfattning

5. Återställning: Deploy från känd bra version (immutable infrastructure), rotera alla komprometterade credentials

6. Rapportering: Intern rapport + GDPR-anmälan till IMY inom 72 timmar + NIS2-rapport till CERT-SE inom 24 timmar

7. Lärande: Blameless post-mortem → uppdatera säkerhetskontroller och playbooks

Utan ett 24/7 SOC som bevakar larm dygnet runt kan ett intrång pågå i veckor innan det upptäcks. Enligt Datadogs State of Cloud-rapporter är bristande observerbarhet en av de vanligaste orsakerna till försenad detektion.

Molnsäkerhet

Kryptering: TLS, at-rest och det som ofta glöms

Data i transit: TLS 1.3 är standard. Acceptera inte TLS 1.0/1.1. Konfigurera HSTS (HTTP Strict Transport Security) med minst 12 månaders max-age och preload.

Data at rest: Använd plattformens inbyggda kryptering (AWS KMS, Azure Key Vault, Google Cloud KMS). Kryptera alltid databaser, backuper och loggar.

Det som ofta glöms:

• Kryptering av data i sessionslagring och cacher (Redis, Memcached)
• Secrets management – inga API-nycklar eller lösenord i kod eller miljövariabler. Använd HashiCorp Vault, AWS Secrets Manager eller Azure Key Vault.
• Certificate management – automatisera certifikatförnyelse med Let's Encrypt/ACM. Vi ser fortfarande driftstörningar orsakade av utgångna certifikat.

FinOps-perspektiv: Säkerhet behöver inte kosta skjortan

Flexeras State of the Cloud har konsekvent visat att kostnadshantering är den största molnutmaningen. Säkerhetslösningar kan snabbt bli dyra om de inte dimensioneras rätt.

Några konkreta tips:

• AWS WAF debiteras per regel och per miljon requests – konsolidera regler och undvik redundanta regelgrupper
• Logglagring i S3 med Intelligent-Tiering istället för att behålla allt i hot storage
• Automatisera skanning – en DAST-skanning mot staging-miljön kostar en bråkdel av en manuell pentest och fångar low-hanging fruit
• Budgetera för penetrationstester – en årlig manuell test av en erfaren testare kostar typiskt 50 000–150 000 SEK beroende på scope, och hittar saker automatiserade verktyg missar

Cloud FinOps

Vanliga frågor

Vad är de vanligaste sårbarheterna i webbapplikationer?

Enligt OWASP Top 10 2021 är bristande åtkomstkontroll (Broken Access Control) den vanligaste kategorin, följt av kryptografiska brister och injektionsattacker som SQL-injektion och XSS. I praktiken ser vi på Opsio att felkonfigurationer – exempelvis öppna S3-buckets eller standardlösenord – ligger bakom en oproportionerligt stor andel av faktiska incidenter.

Hur påverkar NIS2 kraven på webbapplikationssäkerhet i Sverige?

NIS2-direktivet, som implementeras i svensk lag, utökar kretsen av organisationer som måste ha systematiskt säkerhetsarbete. Det inkluderar krav på riskanalys, incidentrapportering inom 24 timmar och ledningens personliga ansvar. Webbapplikationer som hanterar samhällsviktiga tjänster omfattas direkt.

Räcker en WAF för att skydda min webbapplikation?

Nej. En WAF stoppar kända attackmönster men skyddar inte mot logikfel, bristande autentisering eller felkonfigurationer i din applikation. Se WAF som ett nätlås – nödvändigt men inte tillräckligt. Du behöver även säker kodpraxis, penetrationstester och kontinuerlig övervakning.

Vad kostar ett intrång i en webbapplikation för ett svenskt företag?

Kostnaden varierar kraftigt beroende på omfattning, men utöver direkta tekniska kostnader tillkommer GDPR-sanktioner (upp till 4 % av global årsomsättning), förlorade affärer och skadad kundrelation. IMY har utfärdat sanktioner på tiotals miljoner kronor mot svenska organisationer. De indirekta kostnaderna i form av förlorat förtroende är ofta betydligt större.

Hur ofta bör vi penetrationstesta våra webbapplikationer?

Minst en gång per år för verksamhetskritiska applikationer, plus efter varje större release eller arkitekturförändring. Automatiserad DAST-skanning bör köras kontinuerligt i CI/CD-pipelines. Manuell penetrationstestning kompletterar automatiserade verktyg genom att hitta logikfel och kedjeangrepp som skannrar missar.

For hands-on delivery in India, see how Opsio delivers drift.