The XSS flaw: when a comment hides code for your visitors

An XSS (cross-site scripting) flaw happens when a site displays content typed by someone, a comment for instance, without neutralizing it. Other visitors' browsers then take it for the site's own code and run it.

The analogy: the note in the guest book

A restaurant keeps a guest book. One customer writes a kind word, another slips in a fake instruction aimed at the staff: "Hand the till to the bearer of this note." If the restaurant reads every page aloud at each service, without telling a note from an order, the staff might obey.

A site does the same when it displays raw what its users wrote: the browser cannot tell the content's text from the page's code.

Why it is a problem

The code that runs this way runs inside your site's page, with the same rights as the site on the visitor's side. It can, for example:

• change what is displayed (a fake login form, say);
• act on behalf of the visitor;
• try to read what the browser keeps for your site, if that is not protected.

The attack targets your visitors, through your site, and it is your reputation that suffers.

Where it hides

Wherever outside content is displayed: comments, profile names, messages, search boxes that echo what was typed, product descriptions entered by third parties.

Good habits

• Escape on output: convert special characters so they show as text and are never interpreted as code. Modern frameworks do it by default.
• Be wary of "display raw HTML" functions those frameworks offer: use them only on content you control, or cleaned by a dedicated library.
• If you must accept formatting (bold, links), use an allowlist of permitted tags.
• Add a content security policy (CSP) that limits which scripts the browser agrees to run.
• Flag login cookies HttpOnly: page scripts will not be able to read them.

A word on frameworks

Most modern frameworks escape content automatically. The risk comes back when someone deliberately turns that protection off to display formatted text, or builds a page by hand from pieces of text. That is where to look first.

Key takeaway

Everything coming from outside is text, never code. Escape on output, be wary of raw HTML, and add layers of protection.

And for your product?

Applications that display user content generally have at least one area to check. A code audit of your application reviews those places, along with the related rights and cookies. We can talk about it for 30 minutes.

Also worth reading: SQL injection, CORS and session or JWT.