How XSS Actually Works (and How I Tested It Myself)

Last updated on November 24th, 2025 at 03:26 pm

Honesty, I will tell you I did not wake up one day and was enthusiastic about what Cross-Site Scripting was. However, having heard the fact that it existed in the 1990s and people continued to cause havoc in 2025, I was curious. What is the 25-year-old vulnerability is continuing to do to modern websites?

Thus I took some days and tested XSS myself with the help of free tools. This is what needs really happens when such attacks succeed, and the explanation is below as though you are speaking with your friend who is in the technical field but not a specialist in security.

What Even Is XSS?

Cross-site Scripting allows the attacker to implant bad code in sites that you believe to be trustworthy. When you go there, the code functions in your browser – not theirs. It is like a person puts a note in the bag of his or her friend and when this friend opens it, he has access to your things.

According to Microsoft alone, there have been more than 970 cases of XSS since January 2024 and it has been estimated that it has about 68% of websites vulnerable. That’s not a small problem.

The scary part? When attackers steal your cookies, they can steal your personal information and do other actions with your browser even without you noticing it e.g. sending messages or adjusting settings.

The Three Ways XSS Hits You

I practiced all three types through the practice platforms (more later). Here’s how they’re different:

Stored XSS is the nastiest. I loaded a script in one of the comments of a practice site and it remained there forever. All individuals accessing that page were struck down – no additional effort required. Like putting a stake in the ground, that just keeps on being a trap working.

Reflected XSS is sneakier. I made a malicious link which appeared as a normal one, but had some code hidden in the URL. After clicking it the site gave my code a perfect reflection where I was actually responding. Consider phishing email messages with “Click here to verify your account” – but the link does much more than you would have imagined.

The strangest one to digest was on the concepts of DOM based XSS. This one does not even have any contact with the server. This is a weakness that exists totally in the manner in which the JavaScript of the site processes information in your browsers. I would play around with the code of the page using the URL, and the browser would simply do whatever I asked of it without inquiring.

How I Actually Tested This

I did not want to have to bind myself to hack any real websites (it is illegal and simply incorrect), so I resorted to the XSS Game of Google and the Web Security Academy offered by PortSwisher. They both are free and designed with a focus on learning.

There were six challenges in the XSS Game with all of them increasing in difficulty. Level 1? Simple, I simply inserted the following code into the search box to see the result:Easy- All I did was to type the following into one of the search boxes: alert(XSS) Level 6? I was forced to improvise on coding and again context switching.

The laboratories at PortSwigger taught me the mechanisms of actual filters, and the ways through which attackers circumvent these filters. I discovered that developers usually attempt to block clear items such as

What I Learned

After testing these attacks myself, a few things became clear:

Context is everything. A payload that works in a search box won’t work in a URL parameter. Attackers have to understand exactly where their code lands and adjust accordingly.

One layer of defense isn’t enough. The sites that held up best used multiple protections input validation, output encoding, and Content Security Policy all working together.

Small mistakes compound fast. I found that XSS often chains with other vulnerabilities like weak session handling or missing CSRF protections turning a “minor” bug into a full account takeover.

Read:

iFLYTEK AINOTE Air 2 Review: The Smart Student’s Secret Weapon