---
title: "Cross-Site Scripting"
canonical: https://trickest.com/glossary/xss
description: "Cross-site scripting lets an attacker inject script into pages another user's browser renders, running attacker code in the victim's session to steal data or hijack actions."
---

# Cross-Site Scripting

Cross-site scripting (XSS) happens when an application reflects attacker-controlled input into a page without proper encoding, so the victim's browser executes it as script. Because the code runs inside the trusted origin, it inherits the user's session: it can read cookies, make authenticated requests, exfiltrate page contents, or rewrite what the user sees.

There are three common shapes. Reflected XSS bounces a payload straight back in a response, usually through a crafted link. Stored XSS persists the payload in a database or comment field so it fires for every visitor. DOM-based XSS never touches the server; client-side JavaScript writes untrusted input into the page. All three end the same way, with attacker code in the victim's browser.

XSS sits among the long-standing entries in the [OWASP Top Ten](/glossary/owasp-top-ten) because input ends up in HTML, attributes, and script contexts that each need different escaping. Defenders apply context-aware output encoding and add a [Content Security Policy](/glossary/content-security-policy) to limit what injected script can do. Attackers often pair XSS with [CSRF](/glossary/csrf) to chain a forced request with stolen context.

In a Trickest workflow, you crawl an app, harvest every parameter and form, then fuzz reflection points so [web application security](/glossary/web-application-security) testing covers candidates a manual pass would miss.

---
_Markdown source of https://trickest.com/glossary/xss._