Comparison
DOM-based XSSvsHTML sanitisation
DOM-based XSS
the server never saw the payload, because the script read it from the URL fragment and wrote it into the page.
The variant where the injection happens entirely in the browser: a client-side script reads a source it does not control and writes it into a sink that executes it. Because the payload can live in the fragment, it may never reach the server, so server-side logging and filtering see nothing. The sinks are the list to know — `innerHTML`, `document.write`, `eval`, and framework escape hatches like `dangerouslySetInnerHTML`.
Full entry →HTML sanitisation
you needed to accept formatted text, so you parsed it and stripped everything not on the allowed list.
Parsing untrusted markup and removing anything not on an explicit allowlist of elements and attributes, for the case where you genuinely must render user HTML. It has to be allowlist-based and it has to run on a real parser, because blocklists and regexes lose to parser quirks every time. Use a maintained library or the platform's own Sanitizer API; a hand-written one is a vulnerability with a delay on it.
Full entry →