What Is Cross-Site Scripting (XSS)?
Cross-site scripting, or XSS, is a web security vulnerability that lets an attacker inject malicious scripts into a website, which then run in other visitors' browsers. Because the script appears to come from the trusted site, it can steal session cookies, capture keystrokes, redirect users, or deface pages. XSS happens when a site displays user-supplied input without properly sanitizing it. It is one of the most common web vulnerabilities and is prevented by validating input and encoding output.
- What it targets
- Other visitors' browsers, via scripts injected into a trusted site
- Main types
- Stored, reflected, and DOM-based XSS (OWASP)
- Core defense
- Output encoding, input validation, and a Content Security Policy (OWASP)
- Common impact
- Session hijacking, credential theft, defacement, malware redirects
What is cross-site scripting? #
Cross-site scripting, abbreviated XSS, is a vulnerability that lets attackers run their own scripts inside other people's browsers by way of a trusted website. When a site accepts input from users, a comment, a review, a search term, a profile field, and then displays that input to other visitors without properly cleaning it, an attacker can submit input that contains a hidden script instead of plain text. When another visitor loads the page, their browser sees the injected script as legitimate content from the site and executes it. Because the browser trusts anything coming from the site's own domain, that script can do things the attacker could never do from outside, like reading the victim's session cookie, impersonating them, capturing what they type, or silently redirecting them to a malicious page. XSS is consistently among the most frequently found web vulnerabilities. Like SQL injection, covered at /wiki/what-is-sql-injection, it stems from trusting user input, and preventing it is a standard part of /services/website-security.
How does an XSS attack work? #
An XSS attack succeeds when a site reflects or stores user input and later renders it into a page as active HTML or JavaScript rather than inert text. Suppose a website shows your search term back to you on the results page. If the site does not encode that term, an attacker can craft a link containing a script in the search parameter; anyone who clicks the link sees the script execute in their browser under the site's identity. Or consider a product review field: if an attacker submits a review containing a script and the site saves and displays it to every future visitor, the payload runs for all of them automatically. The browser cannot tell the difference between the site's intended code and the injected script because both arrive from the same trusted origin. From there, the script runs with the victim's privileges on that site, able to access cookies, local storage, and the page's contents. The whole attack hinges on the site failing to treat user input as data when it displays it.
What are the three types of XSS? #
Security professionals classify XSS into three main forms. Stored XSS, sometimes called persistent XSS, is the most dangerous: the malicious script is saved on the server, in a comment, review, forum post, or profile field, and served to every visitor who views that content, so a single injection can attack many users automatically. Reflected XSS is non-persistent: the script is not stored but is bounced back immediately in a response, typically through a crafted URL or form submission, so the attacker must trick each victim into clicking a malicious link, often via phishing. DOM-based XSS happens entirely in the browser, when client-side JavaScript takes attacker-controllable input, such as part of the URL, and writes it unsafely into the page without ever involving the server in the vulnerability. Each type requires slightly different testing and defense, but all three share the same cure: never insert untrusted data into a page as executable content. Stored XSS deserves the most urgency because it scales to every visitor, but reflected and DOM-based variants are equally capable of hijacking an individual account.
What damage can XSS cause? #
XSS turns a trusted website into a delivery vehicle for attacks against its own users, and the consequences can be serious. The classic impact is session hijacking: the injected script reads the victim's session cookie and sends it to the attacker, who can then impersonate the victim, potentially including an administrator, and take over their account without ever knowing the password. Scripts can capture keystrokes, harvesting login credentials or payment details as users type. They can rewrite page content to display fake login forms or fraudulent messages, a form of phishing that looks completely legitimate because it is on the real site. They can redirect visitors to malware-hosting or scam sites, or perform actions on the user's behalf, such as changing account settings or making requests. For an e-commerce or membership site, an XSS flaw can lead directly to account takeovers, fraud, and the kind of data exposure detailed at /wiki/what-is-a-data-breach. Because the attack runs under the site's trusted domain, victims have little reason to suspect anything, which makes XSS both effective and reputationally damaging.
How do you prevent cross-site scripting? #
XSS prevention rests on a consistent principle: treat all user input as untrusted and never let it become executable code in a page. The cornerstone defense is output encoding, also called escaping, which converts characters that have special meaning in HTML, JavaScript, or URLs into harmless display equivalents, so a submitted script tag renders as visible text instead of running. Encoding must be applied in the right context, HTML, attribute, JavaScript, or URL, since each has different rules. Input validation adds a layer by rejecting or restricting input that does not match an expected format. A Content Security Policy, or CSP, is a powerful defense-in-depth measure: it tells browsers which sources of scripts are allowed, so even an injected inline script is blocked from executing. Modern frameworks like React and Angular encode output by default, dramatically reducing risk when used correctly, though unsafe functions can reintroduce it. Marking cookies as HttpOnly prevents scripts from reading session cookies, blunting the most common payload. We build these protections into everything we develop under /services/web-app-development, and harden existing sites through /services/website-security.
What does safe output handling look like? #
The practical fix is to encode user data at the moment it is rendered and to avoid dangerous sinks that execute HTML. Inserting untrusted content by setting an element's text is safe because the browser treats it as plain text; inserting the same content as raw HTML is dangerous because a script inside it will run. A Content Security Policy header adds a second line of defense by refusing to execute scripts from unapproved sources. Below, the unsafe pattern writes raw HTML from user input, so any script embedded in that input runs immediately, while the safe pattern sets text content so the same input is displayed as inert characters and nothing executes. The accompanying Content Security Policy header restricts which sources scripts may load from, adding a second line of defense that blocks injected inline scripts even if an encoding mistake slips through. These patterns are language-agnostic and apply equally in server-rendered pages and client-side JavaScript, which is why we standardize on them across the applications we build.
// UNSAFE: raw HTML from user input runs any injected script
el.innerHTML = userComment; // <img src=x onerror=alert(1)> executes
// SAFE: textContent renders input as inert text, never as code
el.textContent = userComment;
// DEFENSE IN DEPTH: send a Content-Security-Policy header
// Content-Security-Policy: default-src 'self'; script-src 'self'
How is XSS different from SQL injection? #
XSS and SQL injection are often mentioned together because both are injection vulnerabilities rooted in trusting user input, but they attack different targets and victims. SQL injection, explained at /wiki/what-is-sql-injection, aims at the server-side database, letting an attacker read or alter the site's stored data directly. XSS aims at the client-side browser, letting an attacker run scripts in the sessions of other visitors. In a SQL injection, the primary victim is the business and its data; in XSS, the primary victims are the site's users, whose accounts and information are compromised through the trusted site. Their defenses share a mindset but differ in mechanics: SQL injection is prevented mainly by parameterized queries that separate data from commands, while XSS is prevented mainly by output encoding and a Content Security Policy that stop input from becoming executable in the browser. A thorough security program addresses both, because attackers probe every input on a site and will exploit whichever weakness they find. We test for both across the applications we build and maintain under /services/web-app-development.
Why do so many sites have XSS flaws? #
XSS remains widespread because modern websites are highly dynamic, displaying user-generated content everywhere, comments, reviews, profiles, search results, chat, and any of those display points can leak if a single one skips proper encoding. The complexity of getting encoding right in every context, HTML body, attributes, JavaScript, URLs, means mistakes are easy, especially in large or older codebases maintained by multiple developers. Third-party components compound the problem: a vulnerable plugin, theme, widget, or advertising script can introduce XSS even when the core site is careful, and outdated components with known flaws are routinely exploited by automated scanners. DOM-based XSS is particularly sneaky because it lives in client-side JavaScript and can be missed by server-focused testing. For small businesses, the usual pattern is a site assembled from many parts without a security review, so a flaw in one plugin or a bit of custom code goes unnoticed until it is abused. The remedies are practical: use well-maintained components, keep everything patched through /services/care-plans, adopt frameworks that encode by default, and have the site tested and hardened by professionals through /services/website-security.
FAQ
What is cross-site scripting (XSS)?
XSS is a vulnerability that lets attackers inject malicious scripts into a trusted website, which then run in other visitors' browsers. Because the browser trusts content from the site's own domain, the script can steal session cookies, capture keystrokes, deface pages, or redirect users. It happens when a site displays user input without properly sanitizing it.
What are the three types of XSS?
Stored XSS saves the malicious script on the server and serves it to every visitor of that content. Reflected XSS bounces the script back immediately, usually via a crafted link a victim must click. DOM-based XSS runs entirely in the browser when client-side JavaScript writes untrusted input into the page unsafely.
How do you prevent XSS?
Encode all user input when rendering it so scripts display as text instead of executing, validate input, and add a Content Security Policy that blocks unapproved scripts. Mark session cookies HttpOnly so scripts cannot read them, and use frameworks that encode output by default. Keep all plugins and components patched.
What can an attacker do with XSS?
Steal session cookies to hijack accounts, including admin accounts, capture keystrokes such as passwords and payment details, display fake login forms to phish users, deface pages, or redirect visitors to malicious sites. Because the script runs under the trusted site's domain, victims rarely suspect anything is wrong.
How is XSS different from SQL injection?
Both are injection attacks that abuse untrusted input, but SQL injection targets the server-side database to steal or change the site's data, while XSS targets visitors' browsers to run scripts in their sessions. SQL injection primarily harms the business's data; XSS primarily harms the site's users' accounts.
Why do so many websites have XSS vulnerabilities?
Modern sites display user content in many places, and any single spot that skips proper encoding can leak. Getting encoding right in every context is error-prone, and vulnerable third-party plugins, themes, and scripts add risk. Outdated components with known flaws are routinely exploited, so unpatched or unreviewed sites are common targets.
Was this helpful?