XSS via the DOM

The JavaScript utility functions used on this page, in particular the URLSearchParams interface, might not work in all browsers: see the list of browsers that support it.

Go to this webpage with a parameter name in the URL, e.g.
http://www.cs.ru.nl/~erikpoll/websec/demo/xss_via_DOM.html?name=John.

The fragment of HTML below uses JavaScript in combination with the DOM to retrieve the parameter name from the URL to include include it in the content of the page. If you change the value of the parameter name, say from 'John' to 'Maria', the webpage show change.


Hello ! Welcome to this webpage.


You can now try to inject HTML mark-up tags, or even scripts, in the parameter name. For instance, try the links below:

Some things you can try:


Note that the DOM-based cross-site scripting on this page is no threat to our web server: you are simply injecting JavaScript that you are running client-side in your own browser. The script is sent to the server, but the server does nothing with it: the server just returns a fixed HTML page, and it is only when your browser renders this page, and executes the JavaScript inside, that the payload in the name parameter fires.
The defence against reflected XSS that used to be built-in browsers, as XSS Filter in Edge and XSS auditor in Chrome, would strip any scripts from a webpage that are identical to scripts passed as parameters in the URL. These defences have been retired in 2018 and 2019. (If you have a really old Edge or Chrome browser, you could try this out if it helps here.) This defence might stop some classic reflected XSS, but it would probably not stop this DOM-based XSS: after all, the script here is not included in the HTML page returned by the server. It is only when the JavaScript code start executing that the malicious scripts are inserted inside the webpage.
A typical XXS injection via the DOM will not be so simple as on this page: