Modern webpages use the language JavaScript to parse and display content. While JavaScript is a robust and widely used framework, which explains its ubiquity, incorrect usage has opened a class of software vulnerabilities called cross-site scripting (XSS) attacks. Today, they are so common that they appear on the Open Web Application Security Project’s Top 10 most frequent web application attacks. 

Sections of web pages, such as input fields on web forms or radio buttons requiring user interactions, are liable to the injection of malicious JavaScript code that can reveal unintended information. When this malicious code is entered in the input field, and in the case of incorrect or unsanitised JavaScript, the webserver reads the malicious code as part of the legitimate JavaScript and reacts accordingly. For example, suppose a programmer wanted to test the sanitisation of their JavaScript code. They might enter a JavaScript string into an input field: if the code is resilient, the “test” string should have no effect, whereas if not, it can cause a pop-up box to appear on the screen. This is a proof of concept, and in practical terms, hackers can disfigure the webpage or target website users’ personal information.

XSS attacks are understood broadly in two forms: the stored XSS and reflected XSS. Stored XSS is where the malicious code is recorded and stored in the database. The resulting information disclosure is persistent agnostic of the user. It is a high-severity vulnerability. Reflected XSS, on the other hand, is an ephemeral attack, where only a specific user may experience the result of the malicious code, which is not stored on the database and arises from misconfiguration on the webpage. As it is much smaller and requires serious intervention to be further exploited, reflected XSS is generally considered a low severity vulnerability. 

Most software frameworks for webpages currently include built-in XSS protections, and the vulnerability is also easy to identify through automated security scanners or penetration tests. However, as best practice, all input fields or other webpage artefacts that rely on user interaction must be sanitised. In other words, they must only accept legitimate inputs by stripping characters that identify malicious code to prevent such attacks.