År 2019 drabbades nästan 75% av stora företag av cross-site scripting. Sju år senare är XSS fortfarande här. Microsoft rapporterade 970 XSS-ärenden som stängts enbart sedan januari 2024, och en sårbarhet 2025 i tillägget LiteSpeed Cache utsatte 7 miljoner WordPress-sajter för risk.

Problemet är inte tekniken. JavaScript, språket för det interaktiva webben, driver varje tema, varje kommentarsfält, varje varukorg. Problemet är att en angripare kan tvinga din sajt att köra deras kod, och webbläsaren kan inte skilja ett skadligt skript från ett legitimt.

Låt oss bryta ner XSS-mekanismerna, tre typer av attacker och specifika skyddslager som skyddar din sajt mot cross-site scripting. Med verktyg, kodexempel och verkliga WordPress-fall.

💡 Snabb översikt:

• Vad XSS är och hur en angripare injicerar skadlig kod i en betrodd sajt
• Tre typer av cross-site scripting (lagrad, reflekterad och DOM-baserad) och hur de skiljer sig åt
• Steg-för-steg-konfiguration av tre skyddslager: WAF, output escaping och Content Security Policy
• Var du ska leta efter XSS-sårbarheter på din sajt och vad du ska göra om en attack redan har inträffat

Vad är cross-site scripting

Cross-Site Scripting är en injektionsattack där en angripare bäddar in ett skadligt skript på en sida hos en betrodd sajt. Offrets webbläsare kör denna kod eftersom den behandlar den som en del av den legitima sidan. Därav namnet: skriptet kommer "korsande sajtgränsen".

Tekniskt sett är attackvektorn inte begränsad till JavaScript. Sårbarheter är möjliga i HTML, Flash, ActiveX och CSS. Men i praktiken riktar sig den överväldigande majoriteten av utnyttjanden mot JS. Anledningen: tillgång till DOM-trädet, cookies, localStorage och förmågan att göra förfrågningar på uppdrag av användaren.

I WordPress uppstår sårbarheter nästan alltid via tillägg och teman som hanterar användarindata felaktigt. Kommentarsfält, sökfält, kontaktformulär, inloggningssidor: varje fält som tar emot data och matar ut den igen utan filtrering blir en ingångspunkt. Enligt Claranet hittades 2570 fall av reflekterad och lagrad XSS i testade webbapplikationer under 2024.

Hur XSS fungerar

En angripare behöver två förutsättningar: en ingångspunkt för skadlig kod och ingen filtrering vid utmatning. I praktiken uppnås detta på två sätt: genom manipulering av användarindata och genom att kringgå same-origin-policyn.

Injektion via användarindata

Det vanligaste scenariot. Ett användarfält (sökfält, kommentarsfält, filuppladdningsfält) tar emot inte bara text utan körbar kod. Om tillägget eller temat inte escape:ar utdata kommer en inmatad <script>alert('XSS')</script> att köras i webbläsaren hos alla som öppnar sidan.

Problemet är djupare än det verkar. Även erfarna utvecklare missar XSS-vektorer genom till synes harmlösa fält: uppladdning av en SVG-fil med ett inbäddat skript, inmatning av data i fältet "användarnamn" vid registrering, URL-parametrar i omdirigeringar. Ett fält utan esc_url() eller esc_attr(), och sajten är exponerad.

I en idealisk värld tar ett sökfält emot vanlig text och inget annat. I det verkliga WordPress-ekosystemet med över 60 000 tillägg är denna garanti ouppnåelig: ett tillägg med echo $_GET['q'] utan esc_html() räcker.

Kringgå same-origin-policyn

Same-origin-policyn är en grundläggande säkerhetsregel i webbläsare: skript från ett ursprung kan inte läsa data från ett annat. En Facebook-sida och en banksida öppna i samma webbläsare utbyter inte information. Men denna regel har en akilleshäl: sessionscookies.

När du loggar in på en sajt skapar webbläsaren en sessionscookie som bekräftar din identitet vid varje förfrågan. Utan den skulle du behöva ange ditt lösenord när du navigerar till varje ny sida. Problemet är att webbläsaren bifogar denna cookie till varje förfrågan till domänen, inklusive förfrågningar initierade av ett skadligt skript.

Attackförlopp: en angripare hittar en XSS-sårbarhet på example.com → injicerar ett skript som läser document.cookie → skickar sessionscookien till sin server. Resultat: fullständig åtkomst till offrets konto utan att känna till lösenordet. Sessionscookies lagrar inloggningsuppgifter, varukorgsinnehåll, fraktinformation: hela användarkontexten.

Tre typer av XSS-attacker

XSS-klassificeringen bygger på var och hur skadlig kod når offret. Det finns tre typer, och för att skydda din webbplats måste du förstå hur var och en fungerar.

Stored XSS (typ I)

Den farligaste typen. Det skadliga skriptet sparas på servern (i databasen, i loggar, i ett kommentarsfält) och körs varje gång den infekterade sidan öppnas. I WordPress är detta ett klassiskt scenario: en angripare lämnar en kommentar med en <script>-tagg, kommentarspluginet filtrerar inte HTML, och skriptet avfyras för varje besökare på inlägget.

Det speciella med stored XSS är att attacken inte behöver aktiveras via en phishing-länk. Offret besöker helt enkelt sidan. Under 2025 var sårbarheten CVE-2025-12709 i Interactions-pluginet för WordPress ett klassiskt exempel på stored XSS på grund av otillräcklig sanering av indata i händelseväljare.

Reflected XSS (typ II)

Angriparen skickar offret en länk som innehåller skadlig kod i URL-parametrar. Servern "reflekterar" tillbaka denna kod i svaret, till exempel i ett sökfelmeddelande eller i raden "Du sökte efter: X." Webbläsaren kör skriptet eftersom det kom i svarskroppen från en betrodd server.

Reflected XSS kräver en aktiv handling från offret: att klicka på en länk. Därför maskeras attacken ofta som en legitim URL i ett phishing-mejl. I WordPress är en typisk angreppsväktor sökplugins som matar ut sökfrågan utan esc_html().

DOM-baserad XSS (typ 0)

Till skillnad från de två första ligger sårbarheten här inte i serverkoden utan i JavaScript på klientsidan. Skadlig data går aldrig till servern; den bearbetas direkt i webbläsaren via osäkra DOM API-metoder som innerHTML, document.write() eller eval().

Datakällan är URL:en (via window.location), document.referrer eller någon annan kontrollerbar källa på klientsidan. Serverloggarna är rena; attacken syns bara i webbläsaren. Denna XSS är svårast att upptäcka eftersom WAF och serverbaserade skannrar inte ser den.

Varför XSS är särskilt farligt för WordPress

WordPress är det främsta målet för XSS av en enda anledning: ekosystemet. Av de över 60 000 plugins i arkivet genomgår inte alla en strikt granskning av output escaping. Ett enda plugin med en sårbarhet komprometterar hela webbplatsen.

I september 2025 publicerade Microsoft en analys av varför XSS fortfarande är ett hot 25 år efter att det uppstod. Den viktigaste slutsatsen: komplexiteten i den moderna webbstacken gör fullständig eliminering av XSS nästintill omöjlig, för många lager där escaping kan missas.

Vad en angripare uppnår via XSS på WordPress:

• Tillgång till adminpanelen genom att stjäla administratörens sessionskakor
• Injektion av dolda länkar (SEO-spam)
• Nedladdning av skadlig kod till besökares datorer
• Manipulering av betalningsuppgifter i WooCommerce
• Massförstörelse av webbplatsens sidor

I kombination med social manipulation blir XSS en vektor för sofistikerade attacker: från installation av keyloggers till cross-site request forgery.

Så skyddar du din webbplats mot XSS: tre lager

XSS-skydd löses inte med en enda inställning. Bara djupförsvar fungerar: säkerhetsplugin blockerar grova angrepp, output escaping stänger tekniska vektorer och Content Security Policy blockerar skriptkörning på webbläsarnivå.

Lager 1: säkerhetsplugin och brandvägg

Första försvarslinjen är ett WordPress-plugin med en Web Application Firewall. WAF filtrerar inkommande förfrågningar innan de når plugin-kod och blockerar kända XSS-angreppssignaturer.

När du väljer säkerhetsplugin, använd den här checklistan:

• Regelbunden skanning efter skadlig kod och kända CVE:er i installerade plugin
• Brandvägg med regler för att blockera XSS-mönster i förfrågningar
• WordPress-härdning: inaktivera XML-RPC, ändra tabellprefix, förhindra filredigering från admin
• Centraliserad hantering av uppdateringar för alla plugin och teman
• Backup, så att du kan återställa webbplatsen om ett angrepp ändå tar sig igenom

Du hittar ett urval av WordPress säkerhetsplugin med detaljerade genomgångar av varje verktygs funktioner i specialiserade recensioner på vår webbplats.

Lager 2: validering och output escaping

Detta är den huvudsakliga tekniska försvarslinjen. Regeln är enkel och icke förhandlingsbar: ingen användardata skickas till webbläsaren utan escaping. WordPress tillhandahåller inbyggda funktioner för detta, och var och en är knuten till en specifik output-kontext.

Grundläggande verktygslåda för WordPress-utvecklare:

1
// For output inside HTML tags — between <p> and </p>
2
echo esc_html($user_input);
3
 
4
// For HTML attributes — inside value="..."
5
echo esc_attr($user_input);
6
 
7
// For URLs in href, src, and other attributes
8
echo esc_url($user_url);
9
 
10
// For output inside <textarea>
11
echo esc_textarea($user_text);
12
 
13
// For JavaScript variables
14
echo esc_js($user_data);
15
 
16
// For allowed HTML tags with dangerous attributes removed
17
echo wp_kses_post($user_html);

Huvudpoängen: funktionsvalet beror på kontext. esc_html() i ett href-attribut räddar dig inte; angriparen lägger in javascript:alert('XSS'). Omvänt släpper esc_url() inuti ett stycke igenom en <script>-tagg. Kontexten avgör funktionen.

wp_kses() förtjänar särskilt omnämnande: ett kraftfullt filter som bara tillåter godkända HTML-taggar och attribut. För användarinnehåll (kommentarer, profilbeskrivningar, anpassade fält) är detta den lägsta nödvändiga filtreringsnivån.

Lager 3: Content Security Policy (CSP)

CSP är en HTTP-header som talar om för webbläsaren: "Kör skript endast från dessa källor." Detta är den sista försvarslinjen. Även om en angripare injicerade en <script>-tagg på sidan kommer webbläsaren inte att köra den eftersom inline-skript inte finns på vitlistan.

Grundläggande CSP-policy för WordPress:

1
// In functions.php or via a plugin
2
function add_csp_header() {
3
    header("Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;");
4
}
5
add_action('send_headers', 'add_csp_header');

En strikt policy ('strict-dynamic' istället för 'unsafe-inline') är säkrare men kräver konfiguration av nonce eller hash för varje legitimt skript. Detta är ett omfattande arbete på en webbplats med ett dussin aktiva plugin. Börja med report-only-läge för att samla överträdelseloggar utan att förstöra frontend:

1
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint

CSP ersätter inte escaping. Det mildrar konsekvenserna av fel när escaping har missats någonstans.

Video: XSS från grunderna till exploatering

För att se XSS i praktiken och förstå hur man hittar sårbarheter på riktiga webbplatser, titta på denna 30-minutersgenomgång:

Efter att du har tittat, återvänd till skyddslagren ovan. Nu kommer de att bli begripliga på mekanisk nivå, inte bara på funktionsnamnsnivå.

⁉️🤔 Vanliga frågor

Hjälper det att uppdatera WordPress och plugin mot XSS?

Ja, och detta är det mest underskattade skyddssteget. Varje ny plugin-version stänger ofta specifika CVE:er, inklusive XSS-sårbarheter. LiteSpeed Cache-sårbarheten CVE-2025-12450 patchades inom en vecka efter upptäckt, men 7 miljoner webbplatser som inte uppdaterade förblev exponerade. Aktivera automatiska uppdateringar för alla plugin; kompatibilitetsproblem är sällsynta, medan en missad patch slår till garanterat.

Räcker ett enda säkerhetsplugin för att skydda mot XSS?

Nej. Ett säkerhetsplugin med WAF fångar kända angreppssignaturer men ser inte nolldagars-sårbarheter och icke-standardiserade vektorer. Det bör vara det första lagret, följt av output escaping i temakod och CSP-headers. Tre lager tillsammans ger ett skydd som inget av dem kan ge ensamt.

Hur kontrollerar jag om min webbplats har XSS-sårbarheter?

Börja med en gratis skanner: WPScan, Sucuri SiteCheck, Qualys SSL Labs. För djupare testning, kör OWASP ZAP (Zed Attack Proxy), ett verktyg med öppen källkod som automatiskt fuzzar inmatningsfält och fångar reflekterad XSS. Viktigt: automatiserade skannrar ser inte DOM-baserad XSS; det kräver manuell granskning av webbplatsens JavaScript-kod.

Kan XSS elimineras helt på en stor webbplats?

Fullständig XSS-eliminering på en webbplats med dussintals plugin och ett anpassat tema är en uppgift nära idealet men svår att helt uppnå. Varje nytt plugin, varje temauppdatering, varje anpassat kodstycke i functions.php är en potentiell ingångspunkt. Ett realistiskt mål: tre skyddslager, automatiska uppdateringar, kvartalsvisa revisioner och CSP i report-only-läge. På så sätt fångar du den överväldigande majoriteten av angrepp i ett tidigt skede.

Vad ska jag göra om min webbplats redan har angripits via XSS?

Byt omedelbart alla lösenord och återställ sessionsnycklar i wp-config.php med hjälp av WordPress-generatorn. Återställ sedan webbplatsen från en ren backup. Efter återställning, installera ett säkerhetsplugin, uppdatera alla plugin och teman till de senaste versionerna och lägg till en CSP-header i functions.php. Lösenord måste bytas eftersom XSS ofta stjäl administratörens sessionskakor.

Är XSS och SQL-injektion samma sak?

Nej, även om båda är injektionsangrepp. SQL-injektion riktar sig mot databasen via en SQL-fråga; angriparen kan läsa, ändra eller radera tabeller. XSS riktar sig mot användarens webbläsare via JavaScript; målet är att stjäla sessioner, visa phishing-formulär eller ändra sidinnehåll. De har olika vektorer, olika skyddsfunktioner ($wpdb->prepare() för SQL, esc_html() för XSS) och olika konsekvenser. Men i praktiken kommer de ofta tillsammans: XSS används för att leverera SQL-injektion via adminpanelen.

Bör du frukta XSS år 2026

XSS har inte försvunnit, men att försvara sig mot det har blivit ingenjörsrutin, inte magi. Tre lager (ett plugin med WAF, output escaping vid alla kontaktpunkter med användaren och en CSP-header) stänger den överväldigande majoriteten av vektorer. Plus automatiska uppdateringar för plugin och teman, så att patchar kommer före exploits.

Om du för närvarande inte använder något av dessa lager, börja med att installera ett säkerhetsplugin och aktivera automatiska uppdateringar i WordPress admin. Detta tar 10 minuter och stänger de grövsta ingångspunkterna. Återvänd sedan till denna artikel när du är redo att implementera escaping och CSP.