What Is Cross-Site Scripting (XSS)?

Cross-site scripting (XSS) is a web vulnerability that allows attackers to run malicious scripts in a victim’s browser while they are using a trusted website. In practical terms, the browser treats attacker-controlled code as if it came from the legitimate application, which can let the attacker alter page behavior, steal data, or abuse the user’s session.

XSS is one of the most common web security issues because modern websites constantly accept and display user-controlled content. For related concepts, see what is sql injection and what is csrf.

How cross-site scripting works

XSS works when attacker-controlled data crosses into a browser context where it can be executed.

The application accepts untrusted input

Most web applications take input from users or browsers all the time, including:

Search terms
Contact forms
Comments and posts
Profile fields
URL parameters
Query strings
Chat messages
Client-side values handled by JavaScript

Input alone is not dangerous. Risk appears when that data is later inserted into a page without the right safeguards.

The application returns that input unsafely

If a site places user-controlled content into HTML, JavaScript, or certain attributes without correct output encoding, the browser may execute it.

For example, a vulnerable page might display submitted content directly inside a template. If that content contains script or browser-interpretable payloads, the site may unintentionally turn user input into executable code.

This can allow an attacker to:

Modify the page
Read visible content
Trick the user with fake forms
Send requests from the trusted origin
Redirect the user
Exfiltrate information from the session context

The victim loads the page

Once the payload is delivered, the victim’s browser executes it in the context of the trusted site. That context is what makes XSS dangerous. The user believes they are interacting with a legitimate application, but the page is now running attacker logic too.

Types of XSS

Stored XSS

Stored XSS happens when the malicious payload is saved by the application and served to users later.

Common examples include payloads inserted into:

Comments
Forum posts
Support tickets
User profiles
Chat messages
Admin review queues

Stored XSS is often more severe because one injection can affect many users without each victim needing a unique phishing link.

Reflected XSS

Reflected XSS happens when the payload is included in a request and immediately reflected into the response.

This often appears in places like:

Search pages
Error messages
Filter results
URL-driven page content

The victim usually has to click a crafted link or submit attacker-controlled input for the attack to work.

DOM-based XSS

DOM-based XSS happens in client-side JavaScript. The browser-side code reads untrusted data from a source like the URL or fragment and inserts it into the DOM unsafely.

In these cases, the server response may look harmless, but the page’s own JavaScript creates the vulnerability.

What attackers do with XSS

The impact of cross-site scripting depends on the application, the victim’s privileges, and browser protections in place.

Common outcomes include:

Session theft or session abuse
Credential harvesting through fake prompts
Page defacement
Sensitive data theft from the visible page
Forced actions in the user’s account
Delivery of phishing content inside a real application
Admin account abuse when a privileged user views the payload

Not every XSS issue leads to full account takeover, but even a limited XSS bug can be serious if it affects internal tools, payment workflows, or administrator dashboards.

When you are likely to encounter XSS

You are most likely to encounter XSS in web application security reviews, penetration tests, bug bounty reports, and OWASP-related discussions.

Common situations include:

User-generated content features: Comments, messaging, support forms, and profile pages are common exposure points
Search and filter pages: Reflected content can create unsafe output paths
Single-page applications: Heavy JavaScript use can introduce DOM-based XSS
Admin panels: A payload becomes more dangerous if reviewed by moderators or administrators
Third-party scripts and widgets: Integrations can introduce unsafe rendering behavior
Custom front-end code: Hand-written DOM manipulation often creates preventable risk

XSS is not limited to old or poorly designed websites. Modern frameworks reduce some exposure, but unsafe rendering patterns, template misuse, and insecure client-side logic still create real risk.

How to prevent cross-site scripting

Preventing XSS depends on treating untrusted data safely in every context where it appears.

Use context-aware output encoding

Output encoding should match where the data is being inserted, such as:

HTML body
HTML attributes
JavaScript contexts
CSS contexts
URLs

This is one of the most important defenses because the same data may be safe in one context and dangerous in another.

Avoid unsafe DOM manipulation

Client-side code should avoid patterns that insert untrusted content directly into the page using unsafe methods. Safer templating and framework defaults are usually better than manual HTML construction.

Validate input where it helps

Input validation is useful for reducing unexpected content, but it is not a complete XSS defense by itself. The bigger control is still safe output handling.

Use Content Security Policy

A well-designed Content Security Policy (CSP) can reduce XSS impact by limiting which scripts a page can execute or load. It is helpful as a defense-in-depth measure, not a replacement for secure coding.

Protect sessions and privileged workflows

Secure cookie handling, reduced session exposure, and tighter admin workflows can limit damage if an XSS issue is exploited.

For teams managing many credentials during web development, testing, or administration, a password manager like Try 1Password → can help reduce insecure credential handling alongside broader security practices.

SQL injection

SQL injection targets the database layer by changing how backend queries are interpreted. XSS targets the browser by changing how a page renders or executes content.

CSRF

Cross-site request forgery tricks a user’s browser into sending unwanted requests. XSS is different because it lets the attacker run script in the application context. In some cases, XSS can make CSRF-style abuse easier.

Injection

Injection is the broader class of vulnerabilities where untrusted data changes how an interpreter handles input. XSS is a client-side injection issue involving browser-executed content.

Session hijacking

Session hijacking is the abuse or theft of a user’s authenticated session. XSS can sometimes enable that outcome, depending on the application’s design and defenses.

Why XSS still matters

Cross-site scripting still matters because trusted web applications are central to work, banking, healthcare, customer support, and internal business operations. If an attacker can execute code inside that trusted environment, they may not need to compromise the server to cause real harm.

For developers, the lesson is to treat output handling as carefully as input handling. For security teams, the lesson is that browser-side attacks can still lead to serious fraud, account compromise, and data exposure.

Final takeaway

Cross-site scripting, or XSS, is a web vulnerability that lets attackers run malicious scripts in a victim’s browser through a trusted site. It usually happens when an application renders untrusted input without proper protection.

The result can range from page manipulation to session abuse, credential theft, or high-impact attacks against privileged users. Preventing XSS requires secure output encoding, safer client-side code, and defense-in-depth controls such as CSP.