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 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 to limit what injected script can do. Attackers often pair XSS with 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 testing covers candidates a manual pass would miss.