Browser parsing quirks still enable XSS bypasses in modern HTML

At a glance

What this is: This research shows that unusual HTML parsing behaviour can turn tag names, attributes, and DOM properties into executable JavaScript or fresh markup.

Why it matters: It matters because application security teams, IAM teams, and identity-adjacent defenders still rely on filters and signatures that assume browser input will remain stable after parsing.

👉 Read PortSwigger's analysis of HTML parsing quirks and XSS bypasses

Context

Cross-site scripting remains a governance problem as much as a coding bug, because controls that inspect raw input often miss what the browser actually interprets. In practice, HTML parsing and DOM mutation can change benign-looking strings into executable script, which means security teams need to test the rendered context, not just the submitted payload. This is a browser behaviour issue, not an exceptional edge case.

PortSwigger's examples also show why security controls that depend on simple deny lists or WAF signatures are brittle. When the browser can normalise tag names, preserve unusual separator characters, or expose alternate DOM properties, attackers gain room to hide payloads from scanners while keeping the exploit functional. The pattern is common wherever the application accepts user-controlled HTML, which is a typical web risk rather than a niche one.

Key questions

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. If a control only inspects the submitted string, it will miss transformations that happen during parsing. Teams should also remove unnecessary HTML sinks and verify behaviour across browser variants.

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. Attackers exploit equivalent forms such as uppercase tags, unusual separators, or alternate DOM properties that a signature may not recognise. A filter that is not parser-aware is always incomplete.

Q: What do security teams get wrong about CSS sanitisation?

A: They often assume that removing scripts makes the problem safe enough. In practice, CSS can still create inference channels through selectors, layout, and remote requests, so the control has to be validated against the client's full rendering behaviour rather than against a narrow syntax filter.

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.

Technical breakdown

How browser parsing turns tag names into execution paths

HTML parsers do not preserve attacker input exactly as written. They normalise tag names, reinterpret separators, and expose multiple DOM views of the same element. That matters because script execution can emerge from properties such as localName, attribute values, or event-handler strings after the browser has transformed the original input. The exploit chain is not magic. It depends on moving from raw text to parsed DOM, then abusing a property that reflects the browser's canonical form instead of the original input. This is why payloads that look invalid in source can still execute in the rendered page.

Practical implication: Test rendered DOM output, not just request payloads, and validate sanitisation against browser parsing behaviour rather than raw string matching.

Why WAF signatures fail against HTML canonicalisation tricks

A WAF usually sees the request before browser canonicalisation. That creates a blind spot when attackers use uppercase, unusual Unicode separators, mixed attributes, or tag-name transformations that the browser later normalises into usable JavaScript. The result is a mismatch between what the filter thinks it blocked and what the browser eventually executes. This is especially dangerous when policies depend on a small set of known bad patterns. Browser leniency gives the attacker many equivalent forms of the same payload, while the filter may only recognise one or two variants.

Practical implication: Use context-aware output encoding and allowlist-based HTML sanitisation, then verify WAF rules against browser-decoded behaviour.

How alternate DOM properties expand the XSS payload surface

Properties such as localName, part, classList, getAttributeNode, and textContent can be repurposed because they return or influence strings that can be fed into constructors, eval-like flows, or dynamic markup assembly. The key technical issue is not a single vulnerable property. It is the ability to chain benign DOM APIs into an execution path once attacker-controlled HTML survives to the browser. That broadens the payload space beyond obvious onfocus or innerHTML abuse and makes source-only review insufficient. Attackers win when the application treats HTML as a string problem instead of a parsing and execution problem.

Practical implication: Review DOM sinks and transform points together, and add security tests that cover non-obvious properties and browser-specific parsing edge cases.

Threat narrative

Attacker objective: The attacker wants arbitrary script execution in the victim's browser while avoiding the filters that were supposed to stop it.

1. Entry occurs when attacker-controlled HTML is accepted into a page or DOM sink that the application treats as safe or only lightly sanitised.
2. Escalation happens when browser canonicalisation turns the supplied markup into a usable execution path through event handlers, attribute values, or alternate DOM properties.
3. Impact follows when the payload executes JavaScript, bypasses blocklists or WAF signatures, and can steal data, alter page state, or trigger further account abuse.

NHI Mgmt Group analysis

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.

HTML injection remains a governance problem because controls rarely model the full transformation chain. Security teams often approve a filter because it blocks one payload form, but the attacker only needs one browser-equivalent variant. This is the same failure pattern seen in other input handling problems: the organisation governs strings, while the attacker exploits semantics. The useful concept here is canonicalisation gap, the distance between what a control inspects and what the browser actually executes. Practitioners should close that gap with parser-aware testing.

WAF bypasses succeed when security programmes rely on pattern rarity instead of semantic safety. The article demonstrates that uppercase tags, separator characters, and alternate properties are not edge cases once a browser accepts them. A WAF that blocks a small set of known bad signatures will always be vulnerable to equivalent encodings. That should push teams toward output encoding, HTML sanitisation libraries, and sink reduction as primary controls, with WAFs acting only as a backstop.

XSS exposure frequently intersects with identity risk because browser execution turns a web flaw into account compromise. Once JavaScript runs in a user's session, the attacker can steal tokens, hijack authenticated flows, or abuse privileged actions without needing the password. That makes XSS relevant to IAM and session governance, not just application security. The practical implication is that identity teams should treat browser-side script execution as a threat to session integrity and access assurance, not just to page content.

Source-aware security engineering needs to test transformation edges, not just code paths. The article's value is that it highlights behaviours the application developer may never have intended, but the browser still accepts. That is why secure coding guidance must be paired with dynamic testing, browser matrix validation, and runtime telemetry on suspicious DOM construction. Teams that only check source strings will continue to miss exploitable variants.

What this signals

Canonicalisation gap: security programmes should treat the difference between source input and browser output as a distinct control surface. That gap is where parser-based bypasses live, and it is why secure input handling must be validated with real browser behaviour rather than static assumptions.

For readers responsible for application security and identity assurance, the next step is to connect web execution risk to session governance. A browser-side XSS exploit can become token theft, account takeover, or privilege misuse, which means app sec findings should feed IAM and incident response workflows.

Browser quirks also argue for more runtime validation in secure development testing. Teams that only inspect code paths or payload strings will keep missing semantically equivalent attacks, while teams that test the rendered DOM and authenticated session impact will find more of the real exposure.

For practitioners

• 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.
• Add identity impact checks to XSS response playbooks When JavaScript execution is possible, treat session tokens, privileged user flows, and authenticated API calls as exposed until the affected browser session is contained.

Key takeaways

• Browser parsing quirks still let apparently blocked HTML become executable JavaScript, which makes raw input filtering an incomplete defence.
• The exploit path matters more than the exact payload, because equivalent browser transformations can bypass signatures, WAFs, and narrow sanitisation rules.
• Identity teams should care about XSS because script execution in an authenticated session can turn a web flaw into token theft and account abuse.

Key terms

• Canonicalisation Gap: The canonicalisation gap is the difference between how a system stores or filters input and how another component later interprets it. In web security, that gap often appears between server-side validation and browser parsing, which allows payloads to remain dangerous after they appear harmless in source form.
• DOM sink: A DOM sink is any browser API or rendering path that can place untrusted data into executable or dangerous HTML context. Examples include innerHTML, script creation, and unsafe SVG handling. If untrusted input reaches a sink without encoding or sanitisation, the result can be script execution.
• Context-Aware Encoding: A defensive practice that transforms output based on where it will be used. HTML, SQL, shell, and template destinations each require different handling, and applying the wrong encoding can leave dangerous characters or instructions executable.
• Client-Side Execution: Client-side execution is the running of code inside the user’s browser after the application has been delivered. It matters because scripts can interact directly with page content, form inputs, and session context, which creates a governance problem that server-side controls do not fully cover.

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.

👉 PortSwigger's full article shows the payload variants, browser transformations, and bypass paths in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to broader security and access-risk decisions across modern enterprise environments.