Vad är XSS (Cross-Site Scripting)? 3 typer och skydd

Hur går en XSS-attack till?

En XSS-attack börjar ofta med att en angripare letar efter sårbara fält där användarinmatning kan skickas till webbapplikationen, till exempel formulär, kommentarsfält eller sökrutor.

Angriparen skriver skadlig JavaScript-kod i ett inmatningsfält där det finns en sårbarhet. Om webbplatsen inte hanterar inmatningen säkert kan koden hamna i sidans HTML. Den skickas då vidare till användarens webbläsare.

En angripare kan till exempel skriva skadlig JavaScript-kod i en bloggkommentar. Om bloggen inte hanterar kommentaren säkert kan koden köras i en annan besökares webbläsare när personen läser kommentaren.

Koden kan till exempel stjäla användarens sessionskakor, omdirigera dem till en skadlig webbplats eller visa falska inloggningsformulär för att fånga upp användarens inloggningsuppgifter.

Olika typer av XSS-attacker

XSS-attacker delas in i tre huvudtyper:

• Reflekterad XSS: Här skickas skadlig kod som en del av en URL och reflekteras tillbaka till användarens webbläsare. Detta sker ofta via e-postlänkar eller länkar på osäkra webbplatser.

  Exempel: En länk som http://www.example-hemsida.se/error?msg="Något gick fel när kontot skulle skapas." kan utnyttjas genom att injicera JavaScript i query-parametern. Om länken istället ser ut som http://www.example-hemsida.se/error?msg=<script>alert('XSS')</script>, och webbapplikationen inte sanerar input, kommer en alert-box med meddelandet "XSS" att visas.

• Lagrad XSS: Skadlig kod lagras permanent på servern, till exempel i en databas, och exekveras varje gång en användare besöker den sårbara sidan.

  Exempel: En angripare kan skriva en kommentar på en blogg som innehåller skadlig JavaScript-kod. Varje gång någon läser kommentaren, exekveras koden.

• DOM-baserad XSS: Skadlig kod injiceras och exekveras genom att manipulera Document Object Model (DOM) i användarens webbläsare, utan att payloaden behöver passera servern.

  Exempel: Om en webbapplikation dynamiskt uppdaterar innehåll baserat på URL-parametrar, kan en skadlig parameter leda till att JavaScript exekveras direkt i användarens webbläsare.

Vad kan XSS-attacker ha för påverkan?

XSS-attacker kan få allvarliga konsekvenser för både användare och webbplatsägare. Dessa attacker kan leda till stöld av känslig information, kapning av användarsessioner och spridning av skadlig kod.

Här är fem specifika exempel på vad som kan hända när en XSS-attack utnyttjas:

• Stöld av känslig information: Angripare kan stjäla användarens inloggningsuppgifter, sessionskakor, personuppgifter och annan känslig information. Detta kan leda till identitetsstöld eller kompromettering av användarkonton, vilket kan ha långvariga effekter på den drabbade individen eller organisationen.
• Kapning av användarsessioner: Genom att stjäla sessionskakor kan angripare få tillgång till användarens pågående session och agera på deras vägnar. Detta kan innebära att angriparen kan ändra användarens inställningar, göra köp eller utföra andra handlingar som användaren inte har godkänt.
• Spridning av skadlig kod: Angripare kan använda XSS för att sprida ytterligare skadlig kod, såsom virus eller spyware, till andra användare som besöker den komprometterade webbplatsen. Detta kan leda till en kedjereaktion där många användare blir infekterade.
• Phishing: Genom att visa falska formulär eller meddelanden kan angripare lura användare att avslöja känslig information, såsom inloggningsuppgifter eller kreditkortsnummer. XSS-attacker används ofta tillsammans med phishing-kampanjer för att skapa mer övertygande bedrägerier.
• Manipulering av webbplatsens innehåll: XSS kan användas för att ändra eller manipulera innehållet på en webbplats. Angripare kan till exempel visa vilseledande information eller ändra visuella element för att lura användare. Detta kan skada webbplatsens rykte och förtroende hos dess användare.

Som tur är finns det effektiva metoder för att skydda sig mot XSS-attacker. Genom att implementera robusta säkerhetsåtgärder kan både användare och webbplatsägare minska risken för att drabbas av dessa allvarliga attacker.

Hur skyddar man sig mot XSS-attacker?

Skyddet behöver passa den plats där data används. Följ OWASP:s vägledning för XSS-skydd:

• Koda utdata för rätt sammanhang. HTML-text, attribut, URL:er och JavaScript kräver olika hantering. HTML-escaping räcker inte överallt.
• Använd säkra DOM-metoder. Skriv vanlig text med exempelvis textContent i stället för att bygga HTML med innerHTML.
• Sanera HTML när den måste tillåtas. Använd ett underhållet bibliotek och undvik att ändra innehållet på ett osäkert sätt efter saneringen.
• Behåll ramverkets skydd. Granska särskilt funktioner som dangerouslySetInnerHTML och andra sätt att kringgå automatisk escaping.
• Använd CSP som extra skydd. En Content Security Policy kan begränsa vilka skript som får köras, men ersätter inte korrekt kodning.

En HttpOnly-kaka kan inte läsas direkt av JavaScript. XSS kan ändå göra anrop med användarens session eller visa falska formulär. Testa därför även beteendet, inte bara om cookies kan läsas. Kombinera kodgranskning med sårbarhetsskanning och tester i en miljö ni har tillstånd att undersöka.

Läs även om att utveckla säker SaaS.

Vanliga frågor

Hur testar jag om min webbplats är sårbar för XSS?

Testa formulär, URL-parametrar och andra datakällor i en miljö ni har tillstånd att undersöka. Kombinera automatiserad skanning med kodgranskning av hur data når HTML och DOM. Ett skript som inte körs bevisar inte att applikationen är säker; olika renderingssammanhang behöver testas separat.

Skyddar moderna ramverk som React automatiskt mot XSS?

Ja, moderna JavaScript-ramverk som React, Vue och Angular har inbyggt skydd mot många vanliga XSS-sårbarheter. De escapar automatiskt användarinmatning vid rendering. Men skyddet är inte komplett - du kan fortfarande införa XSS-sårbarheter genom att använda farliga funktioner som dangerouslySetInnerHTML i React eller genom att direkt manipulera DOM. Validera alltid användarinmatning på serversidan också.

Vad är skillnaden mellan XSS och SQL injection?

XSS injicerar skadlig JavaScript-kod som körs i användarens webbläsare och kan stjäla sessioner eller manipulera innehåll. SQL injection injicerar SQL-kod som körs i databasen och kan läsa, ändra eller radera data. Båda utnyttjar bristande validering av användarinmatning, men angriper olika delar av systemet. Skydden skiljer sig: XSS förebyggs med kontextanpassad kodning av utdata, säkra DOM-metoder och sanering när HTML tillåts. SQL injection förebyggs främst med parametriserade databasfrågor. Indatavalidering kompletterar dessa skydd men ersätter dem inte.

Kan XSS påverka mobila appar?

Ja, mobila appar som använder webbvy (WebView) för att visa innehåll är sårbara för XSS-attacker. Om appen laddar användardata eller extern data i en WebView utan korrekt sanering kan skadlig JavaScript köras. Detta är särskilt riskabelt i hybrid-appar som bygger på webbteknologi. Använd samma säkerhetsåtgärder som för webbapplikationer och begränsa WebView-behörigheter.

Hur allvarlig är en XSS-sårbarhet jämfört med andra säkerhetshot?

XSS klassificeras i OWASP Top 10 (2025) som en del av A05: Injection – kategorin för de vanligaste säkerhetshoten mot webbapplikationer. Konsekvensen beror på var koden körs, vilka användare som berörs och vilka behörigheter deras sessioner har. XSS kan orsaka sessionsmissbruk eller stöld av uppgifter. Prioritera rättningen utifrån exponering och påverkan, inte enbart sårbarhetens namn.