XSS Learning Notes

A practical map of XSS attack surfaces and defense checks, based on PayloadsAllTheThings, OWASP, and MDN.

Testing Method

  1. Identify the output context first: HTML text, attribute, URL, JavaScript string, CSS, DOM sink, or iframe wrapper.
  2. Paste context-specific payloads one by one, and record not only whether they execute but which policy blocks them.
  3. Test delayed surfaces too: admin consoles, notifications, mail, log viewers, previews, and search indexers.

Commonly Missed Surfaces

HTML / attribute

Removing script tags is not enough if event handlers, SVG onload, autofocus/onfocus, or quote breakouts survive.

URL / protocol

href, src, action, and data need protocol allowlists after decoding and normalization.

DOM sink

location, hash, postMessage, or storage values become DOM XSS when they reach innerHTML or string-eval APIs.

Rich text / Markdown

ProseMirror, Markdown, and MDX often store one format and render another. Sanitize the final HTML.

iframe embed

Embed safety needs host/protocol allowlists, sandbox, allow attributes, and referrer policy, not just tag filtering.

Files / Blind XSS

SVG/HTML uploads and admin review screens are classic delayed stored-XSS surfaces.

Defense Checklist

Real Product Questions To Discuss

Community editor and iframe embeds

A ProseMirror editor saved content to a database, then a separate renderer displayed it. Sanitization with DOMPurify helped, but iframe embeds raised a hard question: when users want many providers, is host allowlisting still the right operational model?

Nickname and icon rendering

Profile fields look small, but they are reused everywhere. A nickname in an attribute or an icon URL through a custom renderer can spread stored XSS into comments, notifications, and admin lists.