XSS Using Doubled Characters

What doubled characters change in XSS filters

XSS using doubled characters is not a different browser feature, it is a filter-evasion pattern. The attacker abuses repeated letters, repeated delimiters, or duplicated encodings to make a payload look harmless to a weak validator while the browser still reconstructs executable markup or script.

The technique matters because many defences inspect the raw string once and then trust that result. When parsing rules, normalisation, and decoding steps do not match the browser’s behaviour, the security control can approve input that later becomes active content. That is why this pattern is often grouped with other XSS filter evasion techniques in broader web application attack guidance, including Web Application Attacks Guide.

Why repeated-character tricks defeat weak parsing

Defences fail when they validate before normalising, or when they treat one representation as authoritative. Doubled characters can hide dangerous tokens, split keywords, or confuse denylist logic that expects exact matches instead of canonicalised input.

This is especially dangerous in multi-stage processing, where a request passes through a WAF, application filter, templating layer, and browser with different decoding or interpretation rules. A payload that looks inert in one layer can become active after the next layer resolves encodings or collapses duplicated characters.

In practice, the weakness is not the doubling itself, but inconsistent interpretation. Any control that searches for fragments of script syntax without first bringing the value into a single canonical form is vulnerable to this style of bypass.

How defenders reduce exposure

The most reliable defence is to normalise input before validation, then apply context-aware output encoding at the point where content is rendered. Those two steps should be aligned with the actual sink, because HTML body text, attributes, JavaScript contexts, and URLs each require different handling.

Testing also needs to include adversarial variants, not only obvious payloads. Filters should be exercised against repeated-character, repeated-encoding, and alternate-syntax samples so that the team can see whether the application accepts a value that later becomes dangerous after decoding or parsing.

Defensive review should focus on the full processing chain rather than a single regex or denylist. If a component strips, collapses, or decodes characters differently from the browser, the control boundary is too weak for XSS prevention.

Detection and validation of bypass attempts

Detection is strongest when logs preserve the original input and the normalised form, so analysts can compare what the application received with what it rendered. That makes it easier to spot malformed payloads, filter probes, and repeated-character patterns used in testing or exploitation.

Security teams should also review how the application behaves after patching or filter updates. A successful block is not enough on its own, because a bypass attempt may indicate that another rendering path, template, or output context still accepts the same payload shape.

For a term like this, the most useful validation question is simple: can the application still be tricked by the same malicious string if its characters are duplicated, encoded, or collapsed in a slightly different order?

Related resources from NHI Mgmt Group

• Doubled Character XSS Manipulations
• XSS Using Alternate Syntax
• XSS Using MIME Type Mismatch
• What are the risks of using static credentials in MCP servers?