Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: Browser quirks in tag parsing, attribute handling, and DOM transforms can be chained into working XSS payloads that bypass blocklists and WAF signatures, according to PortSwigger research. The practical lesson is that canonicalisation, context-aware encoding, and browser-side testing matter more than pattern matching alone.
NHIMG editorial — based on content published by PortSwigger: What's in a tag name? JavaScript, apparently
Questions worth separating out
Q: How should security teams defend against XSS payloads that survive HTML parsing quirks?
A: Defence should start with output encoding and safe HTML sanitisation, then move to browser-based testing of the final DOM.
Q: Why do WAFs miss some cross-site scripting attacks?
A: WAFs miss some attacks because they see the raw request, while the browser interprets the payload after normalisation and canonicalisation.
Q: What do security teams get wrong about CSS sanitisation?
A: They often assume that removing scripts makes the problem safe enough.
Practitioner guidance
- Test sanitisation against browser-rendered output Build security tests that compare submitted markup with the final DOM the browser constructs, then verify whether event handlers, attributes, or text nodes become executable after parsing.
- Reduce reliance on WAF signature blocking Treat WAFs as a secondary control and back them with context-aware output encoding, allowlist sanitisation, and sink reduction for any user-supplied HTML.
- Review DOM sinks and transform points Map every place user input reaches innerHTML, setHTMLUnsafe, event attributes, or custom property chains, then retest with alternate properties such as localName, part, and classList.
What's in the full article
PortSwigger's full article covers the exploit variations and browser behaviours this post intentionally leaves at a higher level:
- Step-by-step payload variants showing how localName, part, classList, and getAttributeNode can each be chained into execution.
- Additional browser-specific examples that demonstrate why uppercase tags, unusual separators, and transformed attributes defeat simple blocklists.
- Concrete proof-of-concept markup for each bypass pattern, useful if you need to reproduce the issue in a test environment.
- Follow-on research links that explore related bypass techniques across cookies, URLs, and other browser parsing edge cases.
👉 Read PortSwigger's analysis of HTML parsing quirks and XSS bypasses →
HTML parsing quirks and XSS bypasses: are your filters keeping up?
Explore further
25/08/2026 6:11 pm
Browser canonicalisation is the real security boundary in XSS defence. The article shows that many defences still treat raw input as the decisive control point, even though the browser performs the transformation that determines exploitability. That means payload review, sanitisation, and signature-based blocking all fail if they are not validated against rendered behaviour. The practical conclusion is that browser parsing must be treated as part of the trust boundary, not an implementation detail.
A question worth separating out:
Q: How can browser-based script execution affect identity and access control?
A: If script runs in an authenticated session, it can steal tokens, trigger privileged actions, or pivot into account abuse without a password. That means XSS is also a session integrity issue. Identity teams should treat execution in the browser as a control failure that can undermine access assurance and account trust.
👉 Read our full editorial: Browser parsing quirks still enable XSS bypasses in modern HTML
