Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) image
In this case, an attacker uses malicious scripting to interfere with a trusted website. Since the site doesn’t sanitize user input, the script can be executed in the user’s browser, generally to steal the cookies or session data. 

  • Tester tip: Try using harmless scripts, such as in input fields or URLs. If it actually executes, then the site is vulnerable. 
  • Pro tip: Always escape and validate all user inputs.
Cross-site scripting, also known as XSS, is one of the most prevalent issues you get in web applications. It’s an issue we all need to be very wary of, as it's fairly easily discovered by attackers, but it’s also quite easy to test for.

It’s a type of vulnerability that doesn’t go after the website itself, but instead goes after the user of the application. It works by injecting JavaScript into an input, and that script then runs for whoever is using the page.

When testing, one common technique is to try and make an alert box pop; just a teeny tiny bit of JavaScript, usually something like <script>alert(1)</script>. If you can get that to run, that means your script has executed, and you've found a cross-site scripting issue.

That might seem harmless, but it shows the door is open. A more skilled attacker could go on to do much worse things, like stealing cookies, hijacking sessions, redirecting users to fake websites, or stealing passwords. So even just getting the alert to show is a big red flag.

Types of Cross-Site Scripting:

  • Reflected XSS: If you can get the attack into a URL and send it to someone, like over Slack or social media, and it runs when they open it, that’s a reflected attack. 
  • Persistent XSS: If the script gets saved to the database and runs for anyone who visits the page, that’s a persistent attack. And that’s a really bad one, a critical issue that needs fixing immediately.

Top tips for testers getting started:
  • Start simple by trying to make an alert box pop up; it’s a safe and easy way to show that JavaScript can run.
  • Try placing your JavaScript test input in different places, like form fields or in the URLs.
  • Try saving your test input and check if it runs when other users load the page. If it does, the application might have a persistent XSS vulnerability.
  • Test reflected XSS by copying the full URL and sharing it with a friend (make sure they know you’re testing).
  • If you want to explore further, try using JavaScript to redirect the user or show a fake login screen, this helps you understand how serious the impact can be.
TestBash Brighton 2025 image
On the 1st & 2nd of October 2025 we're back in Brighton for TestBash: the largest software testing conference in the UK
Explore MoT
Xray AI in action: Test Case & Model Generation for modern QA teams image
Wed, 17 Sep
with Ivan Fillipov, Solution Architect at Xray
MoT Software Testing Essentials Certificate image
Boost your career in software testing with the MoT Software Testing Essentials Certificate. Learn essential skills, from basic testing techniques to advanced risk analysis, crafted by industry experts.
Leading with Quality
A one-day educational experience to help business lead with expanding quality engineering and testing practices.
This Week in Testing image
Debrief the week in Testing via a community radio show hosted by Simon Tomes and members of the community
Subscribe to our newsletter
We'll keep you up to date on all the testing trends.