Cross-Site Scripting XSS

What Is XSS

Cross-Site Scripting, or XSS, is one of the oldest and most insidious vulnerabilities on the web. Its essence is simple: an attacker inserts his code (most often JavaScript) into a page, which is then opened by an unsuspecting user. Imagine: you go to the forum, and in a comment someone has “hidden” a script that automatically steals your cookies or redirects you to a fake website. It seems to be an ordinary post on the screen, but someone else’s code is working inside.

XSS is not an interface bug, but a logic error: the site allows you to do things that the user is not supposed to do. That’s why it’s so common — in forms, search, profiles, and comments. Even large platforms (Facebook, YouTube, PayPal) have been victims of XSS more than once.
In terms of consequences, XSS ranges from a harmless pop-up window with “Hello, world!” before the theft of authorization tokens and full control over the account. This is not just a technical hole — it is a window through which an attacker literally “enters” other people’s browser.

Historical Background: How XSS Emerged And Evolved

The history of XSS is the story of the growing up of the Internet itself. In the early 2000s, when websites began to move from static HTML to dynamic content, developers faced a new problem: users could enter data, and servers could display it “as is”. This is how the first XSS exploits appeared: the simplest in comment forms and chat rooms. At first it seemed like a harmless joke, but soon the vulnerability turned into a tool for infection and data theft.

A classic example is the MySpace Worm (2005), when one script in a user’s profile spread to a million accounts per day. Since then, XSS has become synonymous with “trust infection”: you don’t download anything suspicious — the malware comes to you on its own.

With the development of the frontend, new forms of attack have emerged. Previously, XSS was reflected (Reflected) — it depended on the URL, but later it was saved (Stored), where the code “lives” in the site database. Today, DOM-based XSS attacks at the client JavaScript level are becoming more common, where the server is not even involved.

In parallel, protection has also evolved: HTML filters, library functions like htmlspecialchars(), Content Security Policy (CSP), strict data sanitization. However, XSS still remains at the top of OWASP, because vulnerability arises not from technology, but from the human habit of trusting input without verification.

Types of XSS and How They Work

XSS does not have a “single face” — this name hides a whole family of attacks that differ in the mechanism of infection and the level of danger.
Here are the three main varieties that anyone who has ever opened a browser console should know.

• Reflected XSS is the most common and “classic” option. The malicious code is transmitted in the URL or form parameters, and the site — unsuspectingly — displays it back to the user. Example: an attacker sends a link like https://example.com/search?q=. The user clicks, and the page executes this script itself. The danger is that the attack works instantly and does not require hacking the server — just a trusting click is enough.
• Stored XSS. is the most dangerous type. The attacker inserts the code into the site’s database, for example, in a comment, nickname, or profile description. After that, the script is executed for everyone who opens the page. This is no longer a “fleeting” bug, but a full-fledged infection that lives on the server. Such XSS are often used to steal tokens, intercept sessions, and distribute malicious links.
• DOM-based XSS. A modern and insidious look typical of single-page SPA applications. The vulnerability here is not on the server, but in the client JavaScript. The code on the page reads data from a URL, hash, or user input and inserts it into the DOM without verification. Example: document.write(location.hash) without filtering — and hello, XSS is right in the browser. This type of attack is more difficult to detect, but it is most often found in React, Vue, and Angular applications.

In general, XSS works according to a simple principle: if the site shows the user what he entered himself, without verification, it means that the site trusts. And where there is trust without a filter, there is always room for attack. There are lots of types of other attacks, for example you should know how to mitigate DDoS attack and you can check it in our article.

Detection, Exploitation and Prevention (Practical Guide)

An XSS vulnerability that often looks like it’s “invisible.” You can’t see it with your eyes until you run the malicious code. Therefore, detection and protection require a systematic approach.

How to detect XSS:

• Manual testing. The easiest way is to insert something like into the input fields or URL and see if it is reflected on the page.
• Automatic scanners. OWASP ZAP, Burp Suite, Netsparker, Acunetix and other tools are able to check forms, requests and responses for embedded code.
• Source code analysis. SAST/DAST checks are useful for modern frameworks – they look for unsafe constructs like innerHTML, eval, or document.write.

What XSS attacks:

• Session cookies (to steal authorization).
• localStorage and API tokens.
• Input fields, user profiles, comments.
• DOM manipulations that can be used to replace data on the fly.

How to protect yourself:

• Output escaping. Any user data must be filtered before being inserted into HTML, JavaScript, or URLs.
• Content Security Policy (CSP). Sets a “whitelist” of acceptable script sources.
• HttpOnly and secure cookies. They protect cookies from access via JavaScript.
• Template engines. Modern systems (for example, Handlebars, Twig) by default screen input and protect against XSS.

Practical advice:

• Check and filter everything that comes from the client.
• Use the “encode on output” principle rather than “filter on input”.
• Avoid dangerouslySetInnerHTML in React and similar functions.
• Do not disable CSP “for convenience’s sake” — this is your last line of defense.

XSS is not about code hacking, but about trust hacking. If the site learns to be distrustful, it will become much more difficult to attack it.

Impact, Examples and Conclusion

Cross-Site Scripting is not just a “pop—up window with alert(1)”. In practice, XSS can turn into a disaster, both for the average user and for large businesses.

Risks and consequences:

• Compromise of accounts. Using XSS, an attacker can steal cookies and gain access to someone else’s account.
• Phishing and content substitution. The script may show a fake login form or replace the page text with malicious links.
• Financial losses. If the site is linked to payments, an attacker can redirect users to fake payment pages.
• Reputational losses. For companies, XSS is a blow to trust: users lose confidence in the security of the resource.

Real-world examples:

• In 2005, MySpace Samy Worm became a legend — the script in the user’s profile infected more than a million accounts per day.
• In the 2010s, XSS was massively used in advertising networks — a malicious banner executed the code directly in the browser.
• Even large platforms like eBay and YouTube have repeatedly closed vulnerabilities through which it was possible to embed a script in comments.

XSS is not an attack “from the past”, but still an actual threat. It does not require hacking the server, just the carelessness of the developer. But good input validation, strict content policy (CSP), and careful code review can completely shut down most scenarios. In the age of the dynamic web, XSS is a reminder: every line of code should trust only what is verified.