XSS, short for cross-site scripting, is a web security flaw that lets an attacker cause a website to deliver attacker-controlled code to a visitor’s browser. The browser may then run that code with the site’s authority, potentially exposing data or enabling actions as the visitor.
“Cross-site scripting” is the standard technical term, and “XSS” is its established abbreviation. The X in the abbreviation distinguishes the term from CSS, which already means Cascading Style Sheets; it is not a separate kind of attack. XSS is a vulnerability class, not a specific tool or one particular payload.
What the term means and where it comes from
In ordinary web use, a browser keeps information and permissions associated with different website origins separate. An origin is generally defined by a site’s scheme, host, and port. This isolation helps stop one site from freely reading another site’s data. An XSS flaw undermines that protection by making a trusted site serve or run content an attacker controls.
The name describes the cross-site security boundary involved: hostile script is made to run in the context of a site the visitor trusts. The term became established in web security discussions as websites began using browser-side scripts to make pages interactive. The abbreviation XSS is used in technical writing, security reports, software documentation, and conversation. A natural sentence is: “The security review found a stored XSS vulnerability in the comment feature.”
Despite the word “scripting,” the issue is not limited to one scripting language. It is about untrusted content being treated as executable or otherwise active browser content. Modern defenses also account for dangerous HTML, attributes, and URLs, not just script elements.
How an XSS attack works
A typical chain has three parts: an attacker supplies or influences input, a website handles it unsafely, and a visitor’s browser interprets the resulting page in the site’s context. The vulnerable site is the delivery point. A victim does not necessarily have to download a file or install software; viewing an affected page may be enough.
For example, imagine a discussion page that accepts a comment and later displays it to other visitors. If the application inserts the comment into the page as active markup instead of treating it as plain text, a malicious comment could cause browser code to run when a moderator or another reader views the page. In a different case, a search page might reflect a value from a request straight into its response without safely encoding it.
Possible consequences depend on the site and its protections. An attacker might read information available to the page, alter what the visitor sees, or make requests through the visitor’s active session. Browser rules and security controls limit some actions, but they do not make XSS harmless. A flaw can also support convincing page changes, such as presenting a false sign-in prompt.
The main types of XSS
- Stored XSS: Malicious content is saved by an application, then served to visitors later. Common places to examine include comments, profiles, support messages, and other user-generated content. The risk can persist until the unsafe content is removed or correctly handled.
- Reflected XSS: A value supplied with a request is returned in the response without safe handling. The attacker may try to persuade a victim to visit a crafted link or submit a request, but the vulnerable page still has to process the value unsafely.
- DOM-based XSS: Client-side code reads untrusted data and uses it in a dangerous way while building or changing the page. The problem may occur in browser code even when the server’s response does not visibly contain the injected content.
These categories describe how untrusted input reaches the vulnerable browser behavior. A real flaw can involve more than one layer, so the label alone does not establish how serious it is.
Why context and output encoding matter
Web pages combine different kinds of content: text, HTML, attributes, URLs, and sometimes JavaScript or CSS. A character that is harmless in ordinary text can have a special meaning in one of those contexts. That is why there is no single universal “escape everything” transformation that safely handles every place data might appear.
Developers should treat user-provided values as data, not as instructions to the browser. The appropriate defense depends on where the value goes. HTML text needs context-appropriate encoding; a value placed in an attribute or URL needs handling suited to that location. Avoid putting untrusted data into executable script or other active contexts. A well-designed templating system can encode ordinary text automatically, but developers still need to use its safe features correctly.
Input validation is useful for enforcing what an application expects, such as a limited set of characters or a recognized format. It is not a replacement for safe output handling: valid-looking input can still be dangerous in the wrong context. Similarly, removing a few suspicious characters is fragile because attackers may find other ways to express active content.
How XSS differs from related attacks
XSS is often confused with cross-site request forgery, or CSRF. In XSS, attacker-controlled content runs in a site’s browser context. In CSRF, a victim’s browser is induced to send an unwanted request to a site where the victim is already authenticated; the attacker does not necessarily get script to run on that site. The defenses overlap in some applications but are not interchangeable.
XSS also differs from SQL injection. SQL injection targets the way an application sends data to a database query. XSS targets the way a browser interprets content delivered by a web application. Both commonly arise when software fails to keep data separate from instructions, but they occur in different parts of a system and require context-specific defenses.
A content security policy can restrict which scripts a browser will run and can reduce the impact of some mistakes. It is a useful additional layer, not a substitute for fixing unsafe rendering. Cookie settings such as HttpOnly can prevent page scripts from reading a protected cookie, but they do not stop scripts from changing a page or making requests available to that page.
Common misconceptions and problems
- “Only careless visitors are affected.” A victim may only need to open a page or follow a link. The underlying weakness is in how the site handles content.
- “A browser will block all injected code.” Browsers enforce important security boundaries, but they generally cannot know that a trusted site has accidentally included hostile content.
- “Filtering input once solves XSS.” Filtering can miss cases and does not account for every output context. Safe rendering and context-appropriate encoding are central.
- “If a cookie is protected, the flaw has no impact.” Cookie protections can limit one route to account data, but injected code may still perform other actions or deceive the visitor.
- “A scanner finding proves an exploitable flaw.” Automated checks can identify suspicious behavior, but a finding needs review in context. Conversely, a clean scan does not prove that an application is free of XSS.
Prevention and response
For people who use websites, practical steps include keeping browsers and devices updated, avoiding unexpected sign-in prompts, and reporting suspicious page behavior to the site operator. If a page appears to imitate a sign-in screen or asks for unusual information, do not enter credentials until its legitimacy is clear. A visitor cannot reliably repair the website’s underlying vulnerability.
For application teams, useful measures include:
- Use templating and rendering methods that treat ordinary values as text by default.
- Encode output for its precise destination, and avoid inserting untrusted values into executable contexts.
- Review client-side code that reads URL fragments, query values, messages, or other untrusted sources and then updates the page.
- Use a content security policy and secure cookie attributes as additional safeguards, not as the only fix.
- Test pages that display user-generated content, error messages, search terms, and other reflected values, then verify that fixes cover the relevant rendering paths.
- When a flaw is confirmed, remove or neutralize unsafe stored content, correct the code, and assess whether accounts or sessions may have been affected.
Testing should be authorized. Security professionals should work in systems they own or have explicit permission to assess, and should avoid testing that disrupts users or exposes real data. Organizations can use code review, security testing, and responsible vulnerability reporting to find issues before or after release.
Frequently Asked Questions
What does XSS stand for?
XSS stands for cross-site scripting. It is the standard abbreviation for a web security flaw that can make a browser run attacker-controlled content in the context of a vulnerable site.
Is XSS the same as JavaScript injection?
Not exactly. JavaScript injection can describe one way an XSS flaw manifests, but XSS is the broader vulnerability category. The unsafe content may involve other active browser content, and the key issue is how the site handles untrusted input.
Can XSS happen without clicking a link?
Yes. Stored XSS may run when someone visits a page containing previously saved unsafe content. Reflected XSS often involves a crafted request, while DOM-based XSS can result from browser-side code processing untrusted data.
Does HTTPS prevent XSS?
No. HTTPS protects data in transit and helps confirm a secure connection to a site, but it does not correct unsafe application code. A site delivered over HTTPS can still contain an XSS vulnerability.
How can I tell if a website has XSS?
A visitor usually cannot determine this reliably just by looking at a page. Authorized security testing and code review are better ways to assess a site; do not probe systems without permission.
In short
XSS is a well-established web security term for flaws that let attacker-controlled content execute or act in a visitor’s browser under a vulnerable site’s authority. Knowing whether a flaw is stored, reflected, or DOM-based helps explain how it arises, while safe, context-aware rendering is the core way developers prevent it.