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.
Editorial analysis by NHI Mgmt Group, based on content published by PortSwigger: “What's in a tag name? JavaScript, apparently”.
Key questions
Q: What breaks when HTML input filtering only checks the raw string?
A: Raw-string filtering breaks when the browser reinterprets the same input into a different structure than the security control expected.
Q: Why do browser parsing quirks make XSS harder to stop than scanners suggest?
A: Scanners usually look for obvious script execution paths, but browsers interpret HTML in context.
Q: How can security teams find XSS issues that WAFs miss?
A: They should test with real browser rendering paths, not only with signature scans or static payload lists.
Practitioner guidance
- Strengthen output encoding by context Encode data for the exact HTML, attribute, URL, or JavaScript context where it is rendered, rather than applying one generic escaping rule across all sinks.
- Inventory dangerous DOM sinks Identify places where application data reaches innerHTML, setHTMLUnsafe, event handlers, or other executable DOM APIs, then replace or constrain those sinks.
- Test browser parsing behaviour directly Build security tests around real browser rendering, including odd tag names, attribute coercion, and separator characters that may survive server-side sanitisation.
Bottom line: Browser parsing quirks still give attackers room to turn malformed HTML into executable script, which makes input shape alone an unreliable defence.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/08/2026 6:11 pm
Parsing differentials are the real control gap: this article shows that the browser's parsed representation and the defender's filtered representation are often not the same object. That mismatch is why blocklists fail so often against modern XSS payloads. Teams that only test input strings miss the transformation layer where bypasses are created. Practitioners should treat canonicalisation as part of the attack surface, not just a preprocessing detail.
A question worth separating out:
Q: Should organisations prioritise sanitisation or safer DOM APIs for XSS defence?
A: Safer DOM APIs should come first because they reduce the number of places where untrusted input can become executable. Sanitisation is still useful, but it is easier to get wrong when one input can be reused in multiple contexts. The strongest programme combines context-specific encoding with sink reduction and browser-based verification.
👉 Read our full editorial: Browser parsing quirks still enable XSS bypasses in modern HTML