Published: 25 October 2020    Last Updated: 03 July 2023

Whilst Reflected and Stored XSS can generally be addressed through server-side user input encoding (such as through the PHP htmlentities() function) or with browser protections such as Content-Security-Policy – this is not sufficient for DOM-XSS.

Where a dangerous function is used, user input into that function should be limited through user input filtering. An allow-list approach of restricting user input to only known-good input should be used. For example, limiting input to the smallest number of characters possible (such as alphanumerics only) and checking the expected data type (such as limiting input to integers only). This is in contrast to a block-list of known-bad inputs being blocked, which is often less effective due to the large degree of flexibility that JavaScript allows. For a good example of this flexibility, consider something like JScrewIt.

Published: 19 October 2020    Last Updated: 03 July 2023

We’ve previously written about Reflected and Stored Cross-site Scripting, however this time we want to tackle DOM-Based Cross-site Scripting, or DOM-XSS for short. The exploitation of DOM-XSS is frequently very similar to Reflected Cross-site scripting, were the payload is stored within the URL and exploitation occurs where a user can be tricked into clicking the link, such as through a phishing email – but we’ll break it down step by step.

Cross-site Scripting vulnerabilities occur where scripts can be executed within another user’s view of a web application. It can allow for attacks such as virtual defacement of the page, the theft of confidential data, or the distribution of malicious software to users of the site.