What Is Cross-Site Scripting (XSS)? How This Attack Works and How to Stop It

A single unchecked input field is sometimes all it takes for an attacker to run their own code inside someone else's website. That is the core idea behind cross-site scripting, and it remains one of the most persistent problems in web security, even on sites that otherwise look well built.

Most people who ask what a cross-site scripting attack is are picturing something technical and distant, like a mainframe breach in an old movie. In practice, XSS is quieter and closer to home. It hides inside comment boxes, search bars, and URL parameters, waiting for a browser to trust it.

This guide breaks down what XSS actually is, how the attack unfolds step by step, the different forms it takes, and what actually works to stop it, based on patterns seen repeatedly across real incidents.

What Is Cross-Site Scripting (XSS)?

Cross-site scripting is a vulnerability that lets an attacker inject malicious script into a web page that other people view. The browser has no way to tell the injected script apart from code the site owner actually wrote, so it runs it without question.

The word "cross-site" refers to how the attack crosses trust boundaries. A user trusts a site, the site's browser session trusts scripts served from that site, and the attacker exploits that chain by smuggling their own script into it. The site becomes the delivery method, not the target.

This is different from an attack aimed directly at a server. With XSS, the server may be functioning exactly as designed. The actual damage happens inside the victim's browser, using the permissions and session data the victim already has.

How Does a Cross-Site Scripting Attack Work?

An XSS attack generally follows a repeatable pattern, regardless of which variant is used.

Step 1 — Finding an unfiltered input

The attacker looks for a place where user input gets displayed back on a page without being properly checked or cleaned. Comment sections, profile fields, and search results are common targets.

Step 2 — Injecting the script

Instead of typing a normal comment or search term, the attacker submits a snippet of script disguised as regular text. If the application does not sanitize it, that script gets stored or reflected back as-is.

Step 3 — The browser executes it

When another user loads the page, their browser reads the injected script as legitimate site code and runs it automatically. At this point, the attacker's code is now operating inside a real user's session.

Step 4 — The payoff

Depending on what the script was built to do, this can mean stealing session cookies, capturing keystrokes, redirecting the user to a fake login page, or quietly performing actions on the user's behalf.

Types of XSS: Stored vs Reflected vs DOM-Based

Not all XSS attacks behave the same way. Understanding the distinction matters because each type calls for a slightly different defense.

Stored XSS

The malicious script is saved on the server, often in a database, and served to every visitor who views the affected page. A poisoned comment thread is the classic example. This variant tends to affect the widest number of users, since the payload sits and waits.

Reflected XSS

Here the script is not stored anywhere. It travels inside a single request, usually a manipulated link, and gets reflected straight back in the response. It typically requires tricking a specific victim into clicking a crafted URL.

DOM-Based XSS

This variant happens entirely within the browser. The vulnerability lives in how client-side JavaScript handles data, without the server ever seeing the malicious payload. It is often harder to catch with server-side scanning alone.

Real-World XSS Vulnerability Examples

XSS is not a theoretical risk confined to security textbooks. It has repeatedly surfaced in major platforms over the years.

Large social platforms have dealt with self-propagating XSS worms, where a script embedded in a profile automatically copied itself to anyone who viewed that profile, spreading rapidly before it was contained.

Popular content management systems have also faced plugin-level XSS flaws, where a single unpatched extension exposed thousands of individual websites built on that platform at once.

Even well-funded platforms with dedicated security teams have shipped features that unintentionally reflected unsanitized input back to users, proving that XSS risk scales with complexity, not just with the size of the security budget behind a product.

XSS vs CSRF: What's the Difference?

These two are frequently confused because both involve a browser being manipulated, but the mechanics are not alike.

XSS is about injecting and running unauthorized script inside a trusted page. CSRF, or cross-site request forgery, is about tricking a browser into sending a legitimate request the user never intended to make, using their existing authenticated session.

Web Application Security Vulnerabilities: Where XSS Fits In

XSS does not exist in isolation. It sits within a broader category of web application vulnerabilities that includes SQL injection, broken authentication, and insecure deserialization, among others.

What sets XSS apart is how consistently it appears across the OWASP Top 10 list year after year, regardless of shifts in frameworks or development practices. Frameworks have improved default protections, but custom code and third-party integrations keep reintroducing the same gaps.

Any conversation about hardening a web application eventually has to include XSS specifically, because it directly targets the trust between a user's browser and the site they believe they are interacting with safely.

How to Prevent Cross-Site Scripting

Prevention is less about one silver-bullet tool and more about layering several practices together.

Input validation and output encoding

Treat every piece of user-supplied data as untrusted by default. Validate what is allowed on the way in, and encode data properly on the way out, so the browser reads it as text rather than as executable script.

Content Security Policy (CSP)

A well-configured CSP tells the browser exactly which sources of script are allowed to run on a page. Even if malicious script slips through somewhere, CSP can stop the browser from executing it.

HttpOnly and Secure cookie flags

Marking session cookies as HttpOnly prevents client-side scripts, including injected ones, from reading them directly. Pairing this with the Secure flag ensures cookies only travel over encrypted connections.

Regular security testing and code review

Automated scanning catches known patterns, but manual code review catches the logic-based gaps that scanners tend to miss, particularly around custom input handling and third-party components.

Tools That Help Detect XSS Vulnerabilities

No single tool category covers everything, which is why mature security programs combine a few approaches.

Static Application Security Testing (SAST) tools review source code before it ever runs, flagging risky patterns like unsanitized output early in development, before the code reaches production.

Dynamic Application Security Testing (DAST) tools take the opposite approach, probing a running application from the outside the way an attacker would, which helps catch issues that only appear at runtime.

Browser-based extensions and manual testing still play a role too, especially for catching DOM-based XSS, which automated scanners can sometimes miss entirely due to how deeply it depends on client-side logic.

Where Code Signing Fits Into the Bigger Trust Picture

XSS and code signing address two different trust problems, and it is worth being precise about that distinction rather than blurring the two together.

XSS prevention is about stopping unauthorized script from running inside a web page in the first place. Code signing, on the other hand, is about proving that a piece of software or script genuinely comes from the publisher it claims to, and has not been altered since it was signed.

They complement each other rather than substitute for one another. A site can be fully protected against script injection and still need code signing to verify the integrity of downloadable software, installers, or scripts distributed outside the browser context. Organizations serious about end-to-end trust tend to address both fronts, since users interact with a mix of in-browser content and downloadable code, often without noticing the difference.

Conclusion

Cross-site scripting persists not because defenses do not exist, but because trust between browsers and websites is easy to exploit and easy to overlook during development. Every input field, comment box, and URL parameter is a potential entry point if it goes unchecked.

The organizations that handle XSS well are not the ones chasing a single fix. They combine input validation, sensible cookie policies, CSP, and regular testing, while also thinking about trust and integrity more broadly, including how their code and software are verified once they leave the browser environment altogether.