EngEd Community

Section’s Engineering Education (EngEd) Program fosters a community of university students in Computer Science related fields of study to research and share topics that are relevant to engineers in the modern technology landscape. You can find more information and program guidelines in the GitHub repository. If you're currently enrolled in a Computer Science related field of study and are interested in participating in the program, please complete this form .

Understanding Cross-Site Scripting Attacks

December 9, 2021

Cross-site scripting (XSS) is a type of web application vulnerability that attacks a websites user rather than the server itself. XSS allows an attacker to impersonate a vulnerable user and conduct any activities or use any data that the user has access to.

The Open Web Application Security Project publishes the OWASP Top 10 report. It is a list of the most serious web application security concerns. In the OWASP Top 10 of 2017, XSS was the second most prevalent issue and was found in around two-thirds of all applications.

In this article, we’ll go through XSS attacks in detail, their impact, and how to mitigate them.

Disclaimer: This article is for educational purposes only.


  • Basic knowledge of HTML and Javascript

How XSS works

Cross-site scripting is accomplished by fooling susceptible web applications into returning malicious Javascript to users. The attacker gets complete control over how the victim interacts with the app when malicious code is executed inside the victim’s browser by collecting:

  • session cookies
  • user credentials
  • tokens
  • secrets

Among other information.


XSS Attack

First, we need to find a vulnerable website. As we can’t go around testing random websites on the internet, we’ll be carrying out this attack on an intentionally vulnerable website. We’ll be making use of an online vulnerable web application by Acunetix. To use the vulnerable web app, we visit Acunetix vulnerable application.


The next step is to locate an input field where we can paste our script. It could be a username, a search box, a text area, or any other type of input field. Our vulnerable website has a search box, perfect! Now, let’s give it some simple HTML code and see what happens. Type in the following HTML code in the search box and hit the go button:

<!-- the HTML u tag or underline tag is used to give a word an underline in HTML -->


From the screenshot above we can see that the word test is underlined. Perfect! We are getting a reflection on the page. By viewing the application’s source code, we can also see how it’s reflected.

view-page source

Now let’s look for XSS. The most simple XSS payload is the script tag. A script tag can either reference or embed JavaScript code. One of the most common XSS payloads is the use of the JavaScript alert function in a script tag. Let’s try this by entering the following payload in our web application’s search box:



We notice that as soon as we hit the go button after entering our XSS payload, we get an alert box with 1 displayed, which means our payload worked successfully. We just used the alert function within JavaScript to display 1.

Types of XSS

Reflected XSS

This is a one-time XSS. The malicious script is part of the victim’s online application request which is frequently reflected in the application’s response.

Reflected XSS is most commonly employed in targeted attacks where the hacker sends a phishing email with the malicious script in the URL. The attacker could even post a link on a public website and deceive the user into clicking it.

Stored XSS

Also known as Persistent XSS, the payload is saved on the server and can be triggered by a victim without requiring any user interaction outside of the application. This type of XSS happens when the server saves your supplied input somewhere into the server (i.e. a database or cache server).

Stored XSS Example

Let’s go back to our vulnerable web application. We click on the Your profile tab, which presents us with a login page.


Now let’s log in with these default credentials:

username: test
password: test

logged in

Now that we are logged in, let’s inject our payload in the name field and click on the update button to update our profile:



As we can see, we got an alert box. This occurred because the payload was saved in the name field, and the alert box was triggered every time the page was loaded.


The victim’s browser is directly affected by DOM XSS, a local attack. The Document Object Model (DOM), the browser’s API for manipulating and presenting web pages, is used in this attack rather than malicious content being delivered to the server.

The impact of XSS

Through XSS, the attacker can do the following:

  • capture user credentials
  • deface the website
  • impersonate a user
  • carry out user actions

How to mitigate XSS attacks

You may prevent XSS attacks through:

  • the usage of appropriate response headers
  • the filtering of user input
  • the encoding of data on output
  • sanitization of HTML


XSS is a common web vulnerability. Web vulnerability scanners such as burp suite, can be used to carry out XSS tests on web applications. You can read more on XSS here:

Peer Review Contributions by: John Amiscaray