Wat is XSS scripting en hoe voorkom je het?

Cross-Site Scripting (XSS scripting) houdt in dat een website onveilige invoer van een gebruiker als code uitvoert in de browser. Hierdoor kunnen aanvallers gegevens stelen, pagina’s aanpassen of namens gebruikers handelen. Dit is héél belangrijk voor elke beheerder (WordPress, webshops, portalen): één zwak invoerveld is al voldoende voor een serieus lek.

Hierbij een mooie introductievideo als je niet veel wil lezen:

Belangrijkste inzichten

XSS staat voor cross-site scripting. Het probleem ontstaat wanneer onbetrouwbare invoer op een onveilige manier terugkomt in HTML, attributen, JavaScript of de DOM.

De drie bekendste vormen zijn stored XSS, reflected XSS en DOM-based XSS.

De sterkste verdediging bestaat uit context-specifieke output encoding, veilige DOM-methoden, sanitization waar HTML nodig is en een strakke Content Security Policy als extra laag.

Wat is XSS scripting?

XSS is een kwetsbaarheid waarbij een applicatie invoer van een gebruiker accepteert en die later terugplaatst op een manier die door de browser als uitvoerbare code wordt gezien.

In de OWASP Top 10 van 2025 valt XSS onder de categorie Injection, op plaats vijf.

Dat kan gebeuren in een reactieveld, een zoekpagina, een URL-parameter, een profielveld of in front-end code die data uit de browser haalt en direct in de pagina zet.

De kern is dus niet dat een aanvaller per se de server overneemt. De kwaadaardige code draait meestal in de browser van het slachtoffer via een kwetsbare website.

Juist daarom is XSS zo verraderlijk. De browser behandelt die code alsof die van de website zelf komt.

Bron: Cloudflare

Waarom XSS zo’n serieus probleem is

XSS raakt direct aan vertrouwen. Bezoekers gaan ervan uit dat de inhoud van een website veilig is. Zodra een site onbetrouwbare input als code laat uitvoeren, kan een aanvaller dat vertrouwen misbruiken.

Dat kan leiden tot aangepaste pagina-inhoud, misleidende meldingen, ongewenste acties binnen een account, het uitlezen van gegevens die in de browser beschikbaar zijn of het uitvoeren van requests namens een gebruiker. Hoe groot de schade is, hangt af van de rechten van het slachtoffer en van de plek waar de kwetsbaarheid zit.

Voor een simpele website kan dat al leiden tot phishingachtige schermen of misbruik van formulieren. Voor een klantportaal, backoffice of beheeromgeving lopen de risico’s snel verder op.

Hoe ontstaat XSS?

De basis is vaak simpel. Een applicatie accepteert invoer, vertrouwt die invoer te veel en zet die later onveilig terug in de output.

Dat zie je bijvoorbeeld wanneer een zoekterm direct terugkomt op de pagina, wanneer een reactieveld HTML of scriptachtige inhoud verkeerd verwerkt, of wanneer JavaScript data uit de URL of hash leest en met een onveilige methode in de DOM zet.

Het probleem zit dus meestal niet alleen in de invoer. Het echte probleem zit in de combinatie van onbetrouwbare input en onveilige rendering.

Welke soorten XSS zijn er?

Stored XSS

Bij stored XSS wordt kwaadaardige invoer opgeslagen op de server. Denk aan reacties, reviews, profielteksten, supporttickets of forumberichten. Zodra andere bezoekers die inhoud openen, krijgt hun browser die payload te verwerken.

Dit type is vaak extra riskant omdat de payload blijft staan totdat die wordt verwijderd. Daardoor kan één kwetsbare invoer meerdere gebruikers raken.

Reflected XSS

Bij reflected XSS wordt de payload niet opgeslagen, maar direct teruggestuurd in de response. Dat gebeurt vaak via URL-parameters, zoekvelden of foutmeldingen.

Een gebruiker klikt dan bijvoorbeeld op een gemanipuleerde link, waarna de website die parameter onveilig toont op de pagina. De payload wordt dus als het ware teruggekaatst naar het slachtoffer.

DOM-based XSS

Bij DOM-based XSS zit het probleem vooral in client-side JavaScript. De server kan op papier nette output teruggeven, maar front-end code leest data uit bijvoorbeeld de URL, hash of documentlocatie en zet die met een onveilige methode in de DOM.

Daardoor ontstaat de kwetsbaarheid in de browser zelf. Dit type wordt vaak onderschat, juist omdat de fout niet altijd duidelijk zichtbaar is in de serverresponse.

Waarom context bij XSS alles bepaalt

Bij XSS draait veel om context. Data die tussen HTML-tags terechtkomt, vraagt om een andere afhandeling dan data in een attribuut, JavaScript-string, CSS-context of URL.

Een algemene filterregel is daarom vaak niet genoeg. Wat veilig is in de ene context, kan onveilig zijn in een andere. Precies daarom gaat het in sterke XSS-beveiliging niet om één trucje, maar om de juiste afhandeling per plek waar data terechtkomt.

Wat kan een aanvaller met XSS doen?

Als XSS lukt, kan de kwaadaardige code vaak alles doen wat de front-end van die website ook mag doen binnen die sessie. De exacte schade hangt af van de applicatie en van de rechten van de gebruiker.

Denk aan het aanpassen van pagina-inhoud, het tonen van valse formulieren, het uitvoeren van acties namens een gebruiker, het lezen van data uit de pagina of het misbruiken van browsertoegang tot onderdelen van de applicatie.

Bij websites met accounts, dashboards of beheerschermen kan dat leiden tot accountmisbruik, datalekken, merkschade en supportproblemen.

Waar zit bij websites vaak verhoogd XSS-risico?

Het risico loopt vaak op bij onderdelen waar gebruikersdata wordt ingevoerd, opgeslagen, teruggetoond of via JavaScript wordt verwerkt.

• zoekpagina’s en filters
• reacties, reviews en profielvelden
• supportformulieren en chatvensters
• widgets en scripts van derden
• maatwerkvelden in CMS-plugins
• front-end code die data uit de URL leest
• bevestigingsberichten en foutmeldingen

Voor WordPress geldt extra aandacht voor plugins, themafuncties, page builders, custom snippets en eigen JavaScript.

Hoe voorkom je XSS?

XSS voorkom je niet met één losse maatregel. Je hebt meerdere verdedigingslagen nodig die samen werken.

1. Gebruik context-specifieke output encoding

Dit is de basis. Onbetrouwbare data moet veilig worden gecodeerd op basis van de context waarin die data terechtkomt. HTML vraagt dus om een andere afhandeling dan attributen, JavaScript of URL’s.

Veel XSS-problemen ontstaan niet omdat data binnenkomt, maar omdat die later verkeerd wordt gerenderd. Daarom zit hier vaak de kern van de oplossing.

2. Gebruik veilige DOM-methoden

Client-side code is een vaak onderschat risico. Wanneer je alleen tekst wilt tonen, moet je methoden gebruiken die tekst ook echt als tekst behandelen. Onveilige DOM-sinks kunnen van gebruikersdata alsnog uitvoerbare code maken.

Wie veel werkt met maatwerk in JavaScript of met dynamische front-ends, moet dit punt extra serieus nemen.

3. Sanitiseer HTML alleen wanneer HTML echt nodig is

Soms mogen gebruikers bewust beperkte HTML invoeren, bijvoorbeeld in een editor of reviewmodule. In dat geval moet je sanitization toepassen met een aanpak die daarvoor bedoeld is.

Zelf filters bouwen met wat losse regels gaat hier vaak mis. Laat dus alleen HTML toe als dat echt nodig is, en behandel die invoer daarna streng.

4. Zet een strakke Content Security Policy neer

Een Content Security Policy is geen vervanging van veilige output, maar wel een extra laag. Daarmee kun je onder meer beperken welke scripts mogen laden en hoe inline code wordt behandeld.

Dat maakt het uitbuiten van fouten lastiger, al neemt het de onderliggende kwetsbaarheid niet weg.

5. Gebruik frameworks en templates zoals bedoeld

Veel frameworks escapen output standaard. Dat helpt, zolang je die beveiliging niet omzeilt. Zodra je rauwe HTML rendert of eigen renderlogica toevoegt zonder veilige afhandeling, komt het risico terug.

Dat geldt net zo goed voor CMS-templates en maatwerk in thema’s.

6. Houd plugins, thema’s en libraries bij

Voor WordPress en andere CMS-omgevingen zit een flink deel van het risico in verouderde plugins, thema’s en JavaScript-libraries. XSS kan ontstaan door fouten in eigen code, maar ook door fouten in software van derden.

Updaten alleen lost niet alles op, maar verkleint wel het aanvalsoppervlak.

Wat werkt niet als hoofdverdediging?

Veel teams grijpen eerst naar maatregelen die snel voelen, maar in de praktijk tekortschieten. Alleen input filtering is niet genoeg. Alleen blacklists gebruiken is niet genoeg. Alleen een WAF inzetten is niet genoeg. Alleen CSP inzetten is ook niet genoeg.

Verweer tegen XSS werkt pas echt wanneer je invoer, output, front-end code, headers en onderhoud samen bekijkt.

XSS en WordPress. Waar moet je op letten?

XSS in WordPress ontstaat vaak door de combinatie van plugins, themafuncties, formulieren, page builders, widgets en maatwerkcode.

Let extra op zoekfuncties die de zoekterm terugtonen, reacties en reviews, shortcodes, custom fields, scripts van derden, code snippets en eigen JavaScript dat URL-waarden of gebruikersdata direct in de pagina zet.

Voor WordPress-beheerders is de praktische lijn meestal helder. Werk plugins en thema’s bij, beperk het aantal uitbreidingen, gebruik alleen leveranciers met een nette reputatie, laat maatwerk reviewen en kijk kritisch naar elke plek waar gebruikersinvoer terugkomt op de pagina.

Lees meer over hoe je WordPress veilig houdt.

Hoe pak je XSS-beveiliging praktisch aan?

Stap 1. Breng invoer en output in kaart

Bekijk waar gebruikersdata binnenkomt en waar die later terugkomt. Denk aan formulieren, zoekvelden, profieldata, filters, widgets en URL-parameters.

Stap 2. Bepaal per plek de context

Komt data terug in HTML, een attribuut, JavaScript, een URL of via client-side rendering in de DOM? Dat bepaalt welke afhandeling nodig is.

Stap 3. Herstel onveilige rendering

Pas output encoding, veilige templating of sanitization toe op de plekken waar dat nodig is. Vermijd gevaarlijke DOM-sinks als die niet nodig zijn.

Stap 4. Voeg extra lagen toe

Denk aan CSP, dependency-updates, pluginbeheer, code reviews en securitytests op risicovolle onderdelen.

Stap 5. Test opnieuw na wijzigingen

Veel XSS-problemen komen terug na een redesign, pluginwissel of nieuw maatwerk. Test daarom niet één keer, maar structureel bij wijzigingen. Een pentest van je webapplicatie toont aan of XSS in de praktijk te misbruiken is.

Veelgestelde vragen over XSS scripting

Waar staat XSS voor?

XSS staat voor cross-site scripting. Het gaat om een kwetsbaarheid waarbij een website onbetrouwbare invoer zo verwerkt dat de browser van een bezoeker die als code uitvoert.

Wat is het verschil tussen stored en reflected XSS?

Bij stored XSS wordt de payload opgeslagen op de server en later aan meerdere gebruikers getoond. Bij reflected XSS komt de payload direct terug in de response, vaak via een URL-parameter of zoekterm.

Is XSS alleen een probleem voor developers?

Nee. Developers lossen het technisch op, maar site-eigenaren, beheerders, bureaus en marketeers hebben er ook mee te maken, vooral bij plugins, formulieren, maatwerk en contentcomponenten.

Is een Content Security Policy genoeg tegen XSS?

Nee. CSP is een extra laag en geen vervanging van veilige output encoding of veilige DOM-verwerking.

Kan een WordPress-site ook XSS hebben?

Ja. Dat risico zit vaak in plugins, thema’s, formulieren, zoekfuncties, widgets en maatwerkcode. Zeker wanneer gebruikersdata onveilig wordt teruggetoond of front-end scripts onveilige rendering gebruiken.

Conclusie

XSS scripting is een serieuze webkwetsbaarheid waarbij onbetrouwbare invoer als uitvoerbare code in de browser van een bezoeker terechtkomt. De drie bekendste vormen zijn stored, reflected en DOM-based XSS.

De beste aanpak is nuchter en technisch strak. Breng invoer en output in kaart, kijk per context hoe data wordt gerenderd, gebruik veilige DOM-methoden, pas sanitization toe waar HTML nodig is en voeg CSP toe als extra laag. Voor WordPress en andere CMS-sites geldt daarnaast dat pluginbeheer, thema-updates en kritisch omgaan met maatwerk net zo belangrijk zijn.