Cross-Site Scripting (XSS) explained simply

What is it, exactly?

Your site constantly redisplays text typed by visitors: a comment, a customer review, a profile name. The problem appears when that text is redisplayed as-is, without being neutralised first.

If a visitor types an actual piece of code instead of plain text, that code runs in the browser of EVERYONE who views the page — not just theirs. It’s like posting on a public board everything people write on it, without ever checking what they actually wrote.

A concrete example

A “Your review” field on a product page. Instead of writing “Great product”, an attacker drops in a small script. If the site displays it as-is, the moment another customer opens the page, that script runs in THEIR browser, with THEIR rights — never the attacker’s.

A sneakier variant: a “verify your order” link sent by email carries the trap directly in the URL. The victim clicks, the page renders normally, and the script fires in a split second, invisible to the eye.

Why it’s serious

Once it runs in the victim’s browser, the script can steal their session cookie — meaning impersonate them without ever knowing their password — display a fake login form to capture their credentials, or act in their name: change their delivery address, confirm a transfer, post under their identity.

It’s one of the most widespread flaws on the web, classified as A03:2021 – Injection in the OWASP Top 10, precisely because a single overlooked field is enough to expose every one of your visitors.

How to protect yourself

The golden rule: neutralise (escape) anything coming from the visitor before redisplaying it. The character < becomes &lt;, > becomes &gt; — the text stays text, never executable code.

Use your stack’s native escaping: Twig and Jinja escape by default, so does React via JSX, htmlspecialchars() in plain PHP. In JavaScript, always prefer textContent over innerHTML to display text. Add a strict Content-Security-Policy, and set session cookies to HttpOnly: even if a flaw slips through, they stay invisible to the injected script.

How SauronSec detects it

SauronSec drops a harmless marker into every field, then checks the exact CONTEXT where it lands on the page: inside an HTML tag, an attribute, a script block. A mere reflection is never enough to conclude — SauronSec verifies the code would actually execute at that precise spot before reporting anything.

For stored cases (comments, profiles, reviews), an inert marker is planted and then looked for on a separately fetched page, with no payload in the URL: proof it truly persists, not just that it echoed back immediately.