Skip to content
Security Lab

XSS Prevention

AvailableInput and outputBeginner

Untrusted input becomes dangerous when it is treated as code. Compare unsafe and safe rendering of the same text.

Type input, then compare how a vulnerable and a secure renderer would treat it. The lab visualises how the browser parses the result, which characters output encoding changes and what secure code looks like.

Untrusted input is data, not code
Comments, names and search terms come from people you don't control. The danger starts when a page builds HTML by gluing that text in, because the browser can't tell your markup from theirs.
Where the text lands decides the defence
Text inside an element, inside a quoted attribute, or inside a URL is parsed by different rules. Each place needs its own encoding or validation.
Output encoding keeps text as text
Encoding turns characters like < and " into entities such as &lt; and &quot;. The browser then shows them as characters instead of reading them as markup.
Layers, not one wall
Frameworks that render text safely by default, correct encoding, URL validation and a Content Security Policy each stop different mistakes. Correct output encoding is the primary fix; the others limit the damage when something slips through.

What you will learn

  • Recognise untrusted input and where it enters a page.
  • Know which rendering methods treat text as HTML, and which keep it as text.
  • Apply output encoding for the context the data is displayed in.
  • Explain how frameworks and Content Security Policy add layers of defence.

Guided challenge

See all guided challenges