JavaScript Injection Tutorial: Test and Prevent JS Injection Attacks on Website

What is Javascript Injection?

Javascript is one of the most popular technologies and is most widely used for web pages and web applications.

It can be used for realizing different website functionalities. However, this technology can bring some security issues, which the developer and tester should be conscious about.

Javascript can be used not only for good purposes but for some malicious attacks too. One among that is Javascript Injection. The essence of JS Injection is to inject the Javascript code, that will be run from the client-side.

JavaScript Injection

In this tutorial, we will learn more about how to check if Javascript Injection is possible, how JS Injection can be performed and what are the consequences that JS Injection can bring.

Risks of JavaScript Injection

JS Injection brings a lot of possibilities for a malicious user to modify the website’s design, gain website’s information, change the displayed website‘s information and manipulate with the parameters (for example, cookies). Therefore this can bring some serious website damages, information leakage and even hack.

The main purpose of JS Injection is to change the website’s appearance and manipulate the parameters. Consequences of JS Injection can be very different – from damaging website‘s design to accessing someone else’s account.

Why is it Important to Test JS Injection?

Many would ask if testing for JS Injection is really necessary.

Checking for JS Injection vulnerabilities is a part of security testing. Security testing is usually performed only if it was included in the project planning, as it requires time, a lot of attention and checking multiple details.

I have noticed, that during project’s realization it is quite common to skip testing against any possible attacks – including JS Injection. This way the teams try to save the project’s time. However, this practice very often ends with customer’s complaints.

It should be known, that security testing is highly recommended even if it is not included in the project plans. Checking for main possible attacks should be performed – at the same time must check for possible JS Injection vulnerabilities.

Leaving simple Javascript Injection vulnerabilities in the product may cost product’s quality and company’s reputation. Whenever I have learned to test against possible attacks and in general security testing, I never skip this part of testing. This way I am just more sure about the product’s quality.

Comparison with other Attacks

It should be mentioned, that JS Injection is not as risky as SQL Injection, as it is performed on the client side and it does not reach system‘s database as it happens during SQL Injection attack. Also, it is not as risky as XSS attack.

During this attack at times, only the website’s appearance can be changed, while the main purpose of XSS attack is to hack others login data.

However, JS Injection also can cause some serious website damages. It can not only destroy website’s appearance but also become a good basis for hacking other people’s login data.

Recommended Tools

#1) Acunetix

Acunetix logo

Acunetix is a web application security scanner that can identify 7000 vulnerabilities like exposed databases, out-of-bound vulnerabilities, weak passwords, etc.

All the web pages, web apps, complex web applications including the application with multiple JavaScript and HTML5 can be scanned by Acunetix. It scans at a lightning-fast speed and verifies the vulnerabilities are real or not. This application security testing solution makes use of advanced macro recording technology.

Acunetix has the automation functionalities such as scheduling and prioritizing the scans, managing identified issues, and scanning the new builds automatically.

#2) Netsparker

Netsparker logo

Netsparker offers a web application security scanner that is automated as well as fully configurable. It can scan websites, web applications, web services, etc. It identifies the security flaws.

It has functionalities for exploiting the identified vulnerabilities automatically in read-only and safe mode. It confirms the identified issue in this way and also gives proof of the vulnerability. It can identify all forms of SQL injection.

While scanning, Netsparker can identify JavaScript files and provides the list of them through the Knowledge Base panel. It helps the security professionals with ensuring that all the JavaScripts on the target website are secure. Professionals can check them manually.

Checking for JavaScript Injection

When you are starting to test against JS Injection, the first thing you should do is to check if JS Injection is possible or not. Checking for this type of Injection possibility is very easy – when navigated to the website, you have to type in the browser’s address bar code like this:


Checking for Javascript Injection

If a popup window with a message ‘Executed!’ appears, then the website is vulnerable to JS Injection.

popup window

Then in the website‘s address bar, you can try various Javascript commands.

It should be mentioned, that JS Injection is not only possible from the website’s address bar. There are various other website‘s elements, that may be vulnerable to JS Injection. The most important thing is to know exactly the parts of the website which can be affected by Javascript Injection and how to check it.

Typical JS Injection targets are:

  • Various forums
  • Article‘s comments fields
  • Guestbooks
  • Any other forms where text can be inserted.

To test if this attack is possible for the text saving form, despite providing normal text, type Javascript code as mentioned below and save the text in the form and refresh the page.


If in the newly opened page includes a text box with the message ‘Executed!’,  then this type of injection attack is possible for the tested form.

If in both the ways a text box with the message appears, you can try to break the website with more tricky JS Injection methods. Then you can try different injection types – parameters modification or design modification.

Of course, parameters modification is considered as a riskier one than design modification. Therefore, while testing more attention should be dedicated to the parameters modification.

Also, it should be kept in mind, that more vulnerable website‘s parts for Javascript Injection are input fields, where any type of data is saved.

Parameters  Modification

As mentioned earlier, one of the possible Javascript Injection damages is parameters modification.

During this injection attack a malicious user can gain parameters information or change any parameters value (Example, cookie settings). This can cause quite serious risks as a malicious user can gain sensitive content. Such type of injection can be performed using some Javascript commands.

Let’s remember, that Javascript command returning current session cookie is written accordingly:

javascript: alert(document.cookie);

Entered in the browser‘s URL bar, it will return a popup window with current session cookies.

popup window with current session cookies

If the website is using cookies, we can read such information as server session id or other user data stored in the cookies.

It has to be mentioned, that instead of alert() any other Javascript function can be used.

For Example, if we have found a vulnerable website, that stores session id in the cookie parameter ‘session_id‘. Then we can write a function, that changes current session id:

javascript:void(document.cookie=“session_id=<<other session id>>“);

This way the session id value will be changed. Also, any other ways of changing parameters are also possible.

For Example, a malicious user wants to log in as other people. To perform login, the malicious user firstly will change authorization cookie settings to true. If cookie settings are not set as “true“, then cookie value can be returned as “undefined“.

To change those cookie values, a malicious user will perform according to the Javascript command from the URL bar within the browser:


Javascript command

In the result, current cookies parameter authorization=false will be changed to authorization=true. This way a malicious user will be able to gain access to the sensitive content.

Also, it has to be mentioned, that sometimes Javascript code returns quite sensitive information.


For Example, if a website‘s developer wasn‘t cautious enough, it can return username and password parameters names and values also. Then such information can be used for hacking the website or just changing the sensitive parameter’s value.

For Example, with the below code we can change username value:


This way any other parameters value can also be modified.

Website’s Design Modification

Javascript can also be used to modify any website‘s form and in general the website’s design.

For Example, with Javascript you can change any information displayed on the website:

  • Displayed text.
  • Website’s background.
  • Website form’s appearance.
  • Popup window’s appearance.
  • Any other website element’s appearance.

For Example, to change the displayed email address on the website, appropriate Javascript command should be used:


Website's design modification

Few other complicated manipulations with the website’s design are also possible. With this attack we can access and change website’s CSS class also.

For Example, if we would like to change the website’s background image with JS Injection, then the command should be run accordingly:

javascript:void(document.background-image: url(“other-image.jpg“);

Javascript Injection

Also, a malicious user may write Javascript Injection code which is mentioned below in the text inserting form and save it.

javascript: void (alert („Hello!“));

Then every time when a page is opened, a text box with the message “Hello!“ will appear.

Changed website‘s design with Javascript Injection is less risky than parameters modification. However if website‘s design will be changed in a malicious way, then it can cost company‘s reputation.

How to Test against JavaScript Injection

It can be tested in the following ways:

  • Manually
  • With testing tools
  • With browser plugins

Possible Javascript vulnerabilities can be checked manually if you have good knowledge of how it should be performed. Also, it can be tested with various automation tools.

For Example, if you have automated your tests at the API level with SOAP UI tool, then it is also possible to run Javascript Injection tests with SOAP UI.

However, I can only comment from my own experience, that you should have really had good knowledge about SOAP UI tool to test with it for JS Injection, as all the test steps should be written without mistakes. If any test step is written incorrectly, it can cause wrong security testing results as well.

Also, you can find various browser’s plugins for checking against possible attack. However, it is recommended not to forget to check against this attack manually, as it usually returns more accurate results.

I would like to say, that testing manually against Javascript Injection makes me feel more confident and assured about the website’s security. This way you can be sure, that no form was missed while testing and all the results are visible to you.

To test against Javascript Injection you should have general knowledge about Javascript and must know which parts of the website are more vulnerable. Also, you should remember that website may be protected against JS Injection and while testing you should try to break this protection.

This way you will be sure if protection against this attack is strong enough or not.

Possible Protection against this attack

Firstly, in order to prevent this attack, every received input should be validated. Input should be validated every time, and not just when the data is initially accepted.

It is highly recommended not to rely on the client side validation. Also, it is recommended to perform an important logic in the server side.

Many try to protect against Javascript Injection by changing the quotes to double and Javascript code should not be performed in that way.

For Example, if you would write into the comment field anything with quotes <script>…<script/>, those quotes will be replaced with double – <<script>>…<</script>>. This way the entered Javascript code will not be executed.

I have noticed, that replacing quotes by double quotes is a quite common practice to avoid possible JS Injection attacks. However, there are a few ways to encode the quotes to make JS Injection code performed. Therefore changing quotes to double is not a perfect way to protect against this attack.


It should always be kept in mind, that Javascript Injection is one of the possible attacks against websites, as Javascript is one of the most widely used technologies for the websites. Therefore, while testing websites or any other web technologies, it should not be forgotten to test against this attack.

When performing security testing, JS Injection should not be forgotten. Some people consider this testing as a less risky attack as it is performed on the client side.

However, it is the wrong approach and we should always remember, that Javascript Injection can cause serious website‘s damage like sensitive information leakage, parameters changing or hacking the user accounts.

Therefore we should consider this as an important part of testing and it is a part of investment for good product‘s and company’s reputation.

Testing for JS Injection is not very difficult. Firstly you should have general knowledge about Javascript and must know how to check if this attack is possible for the current web solution or not.

Also while testing you should remember, that a website can have protection against this type of attack, but it may be too weak – it should also be checked. Another important thing to remember is that there are different types of Javascript Injection attacks and none of them should be forgotten to test.

Have you performed Javascript Injection Testing?? We would be glad to hear from you, feel free to share your experiences in the comments section below.

Recommended Reading

6 thoughts on “JavaScript Injection Tutorial: Test and Prevent JS Injection Attacks on Website”

  1. Hi this is an interesting article.
    do you know any website which has blocked Javascript injection javascript:alert(‘executed!’); disabled.
    as I can see most of the websites open a pop-up with ‘Executed’. so are they all vulnerable?

  2. should i mention like “websiteURL/javascript:alert(‘Executed!’);” or just “javascript:alert(‘Executed!’);”.
    pleace provide some examples where can we practice.

Comments are closed.