Introduction to Cross Site Scripting(XSS), Explained 2025!

As we know, OWASP(Open-source Web Application Security Project) is a premier organisation in ranking web application vulnerabilities. Now, XSS is one of the top vulnerabilities, having moved from 7th as per the 2017 OWASP ranking to 3rd under injection as per the 2021 OWASP ranking.

What is XSS?

Cross-site scripting, or XSS, is a web application vulnerability that allows you to inject malicious code into web applications. These scripts are then executed by the browsers of other users, allowing the attacker to execute other attacks like session hijacking, stealing credentials, and other malicious activities.

How to identify an XSS vulnerability?

Focus on the website and don’t look at the UI of the page but rather focus on the webpage input fields. The input fields of a website can be vulnerable to XSS, fields like popups that require user inputs, file upload fields that don’t validate file type, form fields that don’t validate type of input, URL parameters like “?name=thedefenderz” that take input without validation are all subjected to XSS vulnerability.

The best way is to upload a string that is unique to you, maybe let us take the example of our website “the defenderz”, the string is highly likely that doesn’t exist in the website you are targeting, use that unique string and try to pass it onto the input fields or URL parameters.

If you can find that the parameter is visible when you inspect or capture it using BurpSuite or Caido try and inject HTML tags or JavaScript like using the “<u>” tag for underlining input parameter or using the “<script>alert()</script> payloads. If you can run it then “hey you have just found an application with XSS vulnerability”.

XSS demonstration from Port Swigger Labs

Here we have an input field of a test website, the input field here is a search tab and can be used to search blogs, articles or any content on the website.

Here let us try and give any input parameter and what we can call it as a payload. For now let’s input a JavaScript test payload “<script>alert()</script>”

Once we run this or click on the search button there are two possibilities, either the search console validates the search and rejects the parameters or it will allow the search bar to process the injected JavaScript payload.

Here we can see that the search bar didn’t validate the input and processed it hence triggering the “alert()” function of the JavaScript written under the “<script>” tag, hence this search bar is vulnerable to XSS.

But once we refresh the alert vanishes meaning the server isn’t affected by the function and hence we can call this as basic XSS or Reflected XSS.