What is Cross-Site Scripting Prevention?

Updated: Nov 25, 2021

Cross-Site Scripting is the act of injecting scripts into an application in order to execute scripts in the context of another user.


glasses in front of computer code

What are the types of cross-site scripting and how can they be prevented?

Cross-site scripting could perform a large variety of malicious attacks from stealing usernames and passwords, to performing actions on behalf of an administrative user in some cases. Many frameworks and libraries have protections built in to prevent this form of attack; however, outdated libraries can frequently allow this form of attack to be successful if they are imported and utilised within applications.


Another issue that can allow for the introduction of Cross-Site Scripting is custom-built applications where proper sanitisation has not been utilised on all user-controlled inputs and outputs.


Cross-Site Scripting executes when the malicious code is allowed to propagate to the browser whether persistently through saved values or reflected via temporary parameters. It is important to ensure that in any areas where a user can input information, whether that be saved data in a form, URL parameters, or one of the many other methods of inputting data, all inputs must be sanitised.


This sanitisation should replace all dangerous characters with encoded versions to ensure that they do not propagate to the page in their original form. This should be performed on data in both directions, i.e. data being entered into the application should be sanitised, and data coming out of the application should also be sanitised to ensure that no malicious code has made it into the database (in the case of persistent Cross-Site Scripting) is able to be displayed on the page in its original executable form. It should also be noted that sanitisation should be carried out server-side as anything client-side can be bypassed via request interception.


Cross-site scripting example

The standard test for Cross-Site Scripting is usually by attempting to inject the following text into an area of the application:


<script>alert(1)</script>

If successful, the application will show a message box with the text “1” as the message. A lot of the time, however, this will not work immediately and requires the attacker to “break out” of the container in which the string is being returned. To do this, the attacker would examine the page and determine how best to do this.


If you like this blog post, find more content in our Glossary.