I 2019 opplevde nesten 75% av store selskaper cross-site scripting. Syv år senere er XSS fortsatt her. Microsoft rapporterte 970 XSS-saker avsluttet bare siden januar 2024, og et sårbarhet i LiteSpeed Cache-utvidelsen i 2025 satte 7 millioner WordPress-nettsteder i fare.

Problemet er ikke teknologien. JavaScript, språket for den interaktive webben, driver hvert tema, hvert kommentarfelt, hver handlekurv. Problemet er at en angriper kan tvinge nettstedet ditt til å kjøre deres kode, og nettleseren kan ikke skille et ondsinnet skript fra et legitimt.

La oss bryte ned XSS-mekanikken, tre angrepstyper og spesifikke beskyttelseslag som skjermer nettstedet ditt mot cross-site scripting. Med verktøy, kodeeksempler og reelle WordPress-caser.

💡 Rask oversikt:

• Hva XSS er og hvordan en angriper sprøyter inn ondsinnet kode i et pålitelig nettsted
• Tre typer cross-site scripting (lagret, reflektert og DOM-basert) og hvordan de skiller seg
• Trinnvis oppsett av tre beskyttelseslag: WAF, output escaping og Content Security Policy
• Hvor du skal se etter XSS-sårbarheter på nettstedet ditt og hva du gjør hvis et angrep allerede har skjedd

Hva er cross-site scripting

Cross-Site Scripting er et injeksjonsangrep der en angriper bygger inn et ondsinnet skript på en side hos et pålitelig nettsted. Offerets nettleser kjører denne koden fordi den behandler den som en del av den legitime siden. Derav navnet: skriptet kommer «kryssende nettstedsgrensen».

Teknisk sett er angrepsvektoren ikke begrenset til JavaScript. Sårbarheter er mulige i HTML, Flash, ActiveX og CSS. Men i praksis retter det store flertallet av utnyttelser seg mot JS. Årsaken: tilgang til DOM-treet, informasjonskapsler, localStorage og muligheten til å gjøre forespørsler på vegne av brukeren.

I WordPress oppstår sårbarheter nesten alltid gjennom utvidelser og temaer som håndterer brukerinput feil. Kommentarfelt, søkefelt, kontaktskjemaer, innloggingssider: ethvert felt som tar imot data og sender dem tilbake uten filtrering blir et inngangspunkt. Ifølge Claranet ble 2570 tilfeller av reflektert og lagret XSS funnet i testede webapplikasjoner i 2024.

Hvordan XSS fungerer

En angriper trenger to forutsetninger: et inngangspunkt for ondsinnet kode og ingen filtrering ved utdata. I praksis oppnås dette på to måter: gjennom manipulering av brukerinput og gjennom omgåelse av same-origin-policyen.

Injeksjon via brukerinput

Det vanligste scenarioet. Et brukerfelt (søkefelt, kommentarfelt, filopplastingsfelt) aksepterer ikke bare tekst, men kjørbar kode. Hvis utvidelsen eller temaet ikke utfører output escaping, vil en inntastet <script>alert('XSS')</script> kjøres i nettleseren til alle som åpner siden.

Problemet stikker dypere enn det ser ut til. Selv erfarne utviklere overser XSS-vektorer gjennom tilsynelatende harmløse felt: opplasting av en SVG-fil med innebygd skript, inntasting av data i «brukernavn»-feltet under registrering, URL-parametere i videresendinger. Ett felt uten esc_url() eller esc_attr(), og nettstedet er eksponert.

I en ideell verden aksepterer et søkefelt ren tekst og ikke noe mer. I det virkelige WordPress-økosystemet med over 60 000 utvidelser er denne garantien uoppnåelig: én utvidelse med echo $_GET['q'] uten esc_html() er nok.

Omgåelse av same-origin-policyen

Same-origin-policy er en grunnleggende sikkerhetsregel i nettlesere: skript fra ett opphav kan ikke lese data fra et annet. En Facebook-side og en bankside åpnet i samme nettleser utveksler ikke informasjon. Men denne regelen har en akilleshæl: sesjonsinformasjonskapsler.

Når du logger inn på et nettsted, oppretter nettleseren en sesjonsinformasjonskapsel som bekrefter identiteten din ved hver forespørsel. Uten den måtte du skrevet inn passordet ditt ved navigering til hver nye side. Problemet er at nettleseren legger ved denne informasjonskapselen til enhver forespørsel til domenet, inkludert forespørsler initiert av et ondsinnet skript.

Angrepsskjema: en angriper finner et XSS-sårbarhet på example.com → sprøyter inn et skript som leser document.cookie → sender sesjonsinformasjonskapselen til sin server. Resultat: full tilgang til offerets konto uten å kjenne passordet. Sesjonsinformasjonskapsler lagrer påloggingsdetaljer, handlekurvinnhold, fraktinformasjon: hele brukerkonteksten.

Tre typer XSS-angrep

XSS-klassifisering baseres på hvor og hvordan ondsinnet kode når offeret. Det finnes tre typer, og for å beskytte nettstedet ditt må du forstå mekanismene bak hver av dem.

Lagret XSS (type I)

Den farligste typen. Det ondsinnede skriptet lagres på serveren (i databasen, i logger, i et kommentarfelt) og kjøres hver gang den infiserte siden åpnes. På WordPress er dette et klassisk scenario: en angriper legger igjen en kommentar med en <script>-tagg, kommentarpluginen filtrerer ikke HTML, og skriptet avfyres for hver besøkende på innlegget.

Det særegne med lagret XSS er at angrepet ikke trenger å aktiveres via en phishing-lenke. Offeret besøker bare siden. I 2025 var sårbarheten CVE-2025-12709 i Interactions-pluginen for WordPress et klassisk lagret XSS-angrep på grunn av utilstrekkelig input-sanitering i hendelsesvelgere.

Reflektert XSS (type II)

Angriperen sender offeret en lenke som inneholder ondsinnet kode i URL-parametere. Serveren «reflekterer» denne koden tilbake i responsen, for eksempel i en søkefeilmelding eller i linjen «Du søkte etter: X». Nettleseren kjører skriptet fordi det ankom i responskroppen fra en pålitelig server.

Reflektert XSS krever aktiv handling fra offeret: å klikke på en lenke. Derfor er angrepet ofte forkledd som en legitim URL i en phishing-e-post. På WordPress er en typisk vektor søkepluginer som sender ut søkeforespørselen uten esc_html().

DOM-basert XSS (type 0)

I motsetning til de to første ligger sårbarheten her ikke i server-side-kode, men i JavaScript på klientsiden. Ondsinnede data går aldri til serveren; de prosesseres direkte i nettleseren gjennom usikre DOM API-metoder som innerHTML, document.write() eller eval().

Datakilden er URL-en (via window.location), document.referrer eller en hvilken som helst annen kontrollerbar kilde på klienten. Serverloggene er rene; angrepet er kun synlig i nettleseren. Denne XSS-typen er vanskeligst å oppdage fordi WAF og server-side-skannere ikke ser den.

Hvorfor XSS er spesielt farlig for WordPress

WordPress er det fremste målet for XSS av én grunn: økosystemet. Av de over 60 000 pluginene i repositoriet er det ikke alle som gjennomgår streng kontroll av output escaping. Én plugin med en sårbarhet kompromitterer hele nettstedet.

I september 2025 publiserte Microsoft en analyse av hvorfor XSS fortsatt er en trussel 25 år etter at det dukket opp. Hovedkonklusjonen: kompleksiteten i den moderne web-stakken gjør fullstendig eliminering av XSS nesten umulig, for mange lag der escaping kan bli glemt.

Hva en angriper oppnår gjennom XSS på WordPress:

• Tilgang til administrasjonspanelet ved å stjele administratorers sesjonsinformasjonskapsler
• Injisering av skjulte lenker (SEO-spam)
• Nedlasting av skadevare til besøkendes datamaskiner
• Bytte ut betalingsdetaljer i WooCommerce
• Massiv defacing av nettstedets sider

Kombinert med sosial manipulering blir XSS en vektor for sofistikerte angrep: fra installering av keyloggere til cross-site request forgery.

Slik beskytter du nettstedet ditt mot XSS: tre lag

XSS-beskyttelse løses ikke med én enkelt innstilling. Kun forsvar i dybden fungerer: sikkerhetsplugins blokkerer grove angrep, output escaping lukker tekniske vektorer, og Content Security Policy blokkerer skriptkjøring på nettlesernivå.

Lag 1: sikkerhetsplugins og brannmur

Første forsvarslinje er en WordPress-plugin med en Web Application Firewall. WAF filtrerer innkommende forespørsler før de når plugin-kode og blokkerer kjente XSS-angrepssignaturer.

Når du velger en sikkerhetsplugin, bruk denne sjekklisten:

• Regelmessig skanning etter skadevare og kjente CVE-er i installerte plugins
• Brannmur med regler for å blokkere XSS-mønstre i forespørsler
• WordPress-herding: deaktivere XML-RPC, endre tabellprefiks, hindre filredigering fra admin
• Sentralisert administrasjon av oppdateringer for alle plugins og temaer
• Sikkerhetskopi, slik at du kan gjenopprette nettstedet hvis et angrep likevel slipper gjennom

Du finner et utvalg av WordPress sikkerhetsplugins med detaljerte gjennomganger av hvert verktøys funksjoner i spesialiserte anmeldelser på nettstedet vårt.

Lag 2: validering og output escaping

Dette er den viktigste tekniske forsvarslinjen. Regelen er enkel og ikke til forhandling: ingen brukerdata sendes til nettleseren uten escaping. WordPress har innebygde funksjoner for dette, og hver av dem er knyttet til en spesifikk output-kontekst.

Grunnleggende verktøykasse for WordPress-utviklere:

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);

Hovedpoenget: funksjonsvalg avhenger av kontekst. esc_html() i en href-attributt redder deg ikke; angriperen vil sette inn javascript:alert('XSS'). Omvendt vil esc_url() inne i et avsnitt slippe gjennom en <script>-tag. Kontekst avgjør funksjonen.

wp_kses() fortjener spesiell omtale: et kraftig filter som kun tillater tillatte HTML-tagger og attributter. For brukerinnhold (kommentarer, profilbeskrivelser, egendefinerte felt) er dette minimumsnivået for filtrering.

Lag 3: Content Security Policy (CSP)

CSP er en HTTP-header som forteller nettleseren: «Utfør skript kun fra disse kildene.» Dette er den siste forsvarslinjen. Selv om en angriper har injisert en <script> på siden, vil ikke nettleseren kjøre den fordi innebygde skript ikke er på hvitelisten.

Grunnleggende CSP-policy for 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 streng policy ('strict-dynamic' i stedet for 'unsafe-inline') er sikrere, men krever konfigurering av nonce eller hasher for hvert legitimt skript. Dette er betydelig arbeid på et nettsted med et dusin aktive plugins. Start med report-only-modus for å samle bruddlogger uten å ødelegge frontend:

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

CSP erstatter ikke escaping. Det demper konsekvensene av feil når escaping har blitt glemt et sted.

Video: XSS fra grunnleggende til utnyttelse

For å se XSS i aksjon og forstå hvordan du finner sårbarheter på ekte nettsteder, se denne 30-minutters gjennomgangen:

Etter å ha sett, gå tilbake til beskyttelseslagene ovenfor. Nå vil de gi mening på det mekaniske nivået, ikke bare på funksjonsnavnnivå.

⁉️🤔 Ofte stilte spørsmål

Vil oppdatering av WordPress og plugins bidra til å beskytte mot XSS?

Ja, og dette er det mest undervurderte beskyttelsestrinnet. Hver nye plugin-versjon lukker ofte spesifikke CVE-er, inkludert XSS-sårbarheter. LiteSpeed Cache-sårbarheten CVE-2025-12450 ble patchet innen en uke etter oppdagelse, men 7 millioner nettsteder som ikke oppdaterte forble eksponert. Aktiver automatiske oppdateringer for alle plugins; kompatibilitetsproblemer er sjeldne, mens en ubesvart oppdatering garantert rammer.

Er én sikkerhetsplugin nok til å beskytte mot XSS?

Nei. En sikkerhetsplugin med WAF lukker kjente angrepssignaturer, men ser ikke nulldagssårbarheter og ikke-standard vektorer. Den bør være det første laget, etterfulgt av output escaping i temakode og CSP-headere. Tre lag sammen gir beskyttelse som ingen av dem kan gi alene.

Hvordan sjekker jeg om nettstedet mitt har XSS-sårbarheter?

Start med en gratis skanner: WPScan, Sucuri SiteCheck, Qualys SSL Labs. For dypere testing, kjør OWASP ZAP (Zed Attack Proxy), et åpen kildekode-verktøy som automatisk fuzzer input-felt og fanger opp reflektert XSS. Viktig: automatiserte skannere ser ikke DOM-basert XSS; det krever manuell revisjon av nettstedets JavaScript-kode.

Kan XSS elimineres fullstendig på et stort nettsted?

Fullstendig XSS-eliminering på et nettsted med dusinvis av plugins og et tilpasset tema er en oppgave nær idealet, men vanskelig å oppnå fullt ut. Hver ny plugin, hver temaoppdatering, hver tilpasset snippet i functions.php er et potensielt inngangspunkt. Et realistisk mål: tre beskyttelseslag, automatiske oppdateringer, kvartalsvise revisjoner og CSP i report-only-modus. På denne måten vil du fange opp det store flertallet av angrep på et tidlig stadium.

Hva bør jeg gjøre hvis nettstedet mitt allerede har blitt angrepet via XSS?

Endre alle passord umiddelbart og tilbakestill øktnøkler i wp-config.php ved hjelp av WordPress-generatoren. Gjenopprett deretter nettstedet fra en ren sikkerhetskopi. Etter gjenoppretting, installer en sikkerhetsplugin, oppdater alle plugins og temaer til siste versjon, og legg til en CSP-header i functions.php. Passord må endres fordi XSS ofte stjeler administratorøkter.

Er XSS og SQL-injeksjon det samme?

Nei, selv om begge er injeksjonsangrep. SQL-injeksjon retter seg mot databasen gjennom en SQL-spørring; angriperen kan lese, endre eller slette tabeller. XSS retter seg mot brukerens nettleser gjennom JavaScript; målet er å stjele økter, vise phishing-skjemaer eller endre sideinnhold. De har forskjellige vektorer, forskjellige beskyttelsesfunksjoner ($wpdb->prepare() for SQL, esc_html() for XSS) og forskjellige konsekvenser. Men i praksis kommer de ofte sammen: XSS brukes til å levere SQL-injeksjon via adminpanelet.

Bør du frykte XSS i 2026

XSS har ikke forsvunnet, men å forsvare seg mot det har blitt ingeniørrutine, ikke magi. Tre lag (en plugin med WAF, output escaping ved alle kontaktpunkter med brukeren og en CSP-header) lukker det store flertallet av vektorer. Pluss automatiske oppdateringer for plugins og temaer, slik at patcher kommer før exploits.

Hvis du for øyeblikket ikke bruker noen av disse lagene, start med å installere en sikkerhetsplugin og aktivere automatiske oppdateringer i WordPress-admin. Dette tar 10 minutter og lukker de groveste inngangspunktene. Kom så tilbake til denne artikkelen når du er klar til å implementere escaping og CSP.