Reflected XSS occurs when malicious scripts are included in URLs and immediately reflected back to users without proper sanitization. These attacks typically require social engineering to convince users to click malicious links. Prevention involves input validation, output encoding, and implementing Content Security Policy headers.
Reflected cross-site scripting happens when a web application takes input from a request, usually a URL query parameter, a search term, or a form field, and echoes it straight back into the HTML response without encoding it. If an attacker crafts a link whose parameter contains a script, the server reflects that script into the page and the victim's browser executes it as if the site had written it. The payload is not stored anywhere; it lives only in that single request, so each attack needs a fresh malicious link. A typical vector is a search results page that prints your query verbatim, or an error page that repeats an unescaped value taken from the URL.
Because the injected script runs in the victim's browser under the site's own origin, it inherits that origin's trust. It can read non-HttpOnly cookies, session tokens, and page content, submit forms, or rewrite what the user sees, which enables session hijacking, credential theft, and phishing that appears to come from the real domain. Reflected XSS usually relies on social engineering: an attacker has to get the victim to click a booby-trapped link from email, chat, or a malicious ad, so it often targets logged-in users of banking, webmail, or admin panels. A single vulnerable parameter can compromise any account whose owner opens the link.
The core defenses are developer-side: validate input, and apply context-aware output encoding so reflected values render as text, never as markup or script. A Content Security Policy adds a second layer by restricting which scripts may run, and framework auto-escaping closes most cases by default. cside is not a substitute for output encoding; its focus is the third-party scripts a page loads. Where an XSS foothold or a compromised vendor script tries to load or exfiltrate through the browser, cside's Script method inspects the actual JavaScript payload, can block that behaviour in real time, and keeps a forensic record, which also supports PCI DSS 6.4.3 and 11.6.1 script-monitoring requirements.
Its blast radius is usually smaller, because the payload is not saved on the server, so it only affects users who open a specific crafted link rather than everyone who views a page. But the in-browser capabilities are identical, and against a high-value logged-in target a single click can be enough to hijack an account.
No. The HttpOnly flag only hides a cookie from JavaScript, so it limits token theft, but a reflected script can still act inside the session, read page data, submit requests, and deface the interface. HttpOnly is a useful mitigation, not a fix; you still need output encoding and a strong CSP.
We answer client-side security questions every day. Bring yours.