Unicode Combining Characters

What Combining Characters Do in Unicode

Unicode combining characters are not standalone letters in the usual sense, they modify the preceding code point. That matters because the same visible text can be encoded in more than one way, and those differences can affect search, sorting, matching, rendering, and security controls that compare strings byte-for-byte or without normalisation.

In practice, combining marks are part of Unicode’s richer text model, which supports accents, diacritics, and other script-specific marks. The security implication is not that the characters are inherently dangerous, but that systems which assume a one-to-one relationship between “character” and “code point” can mis-handle them.

Why Combining Marks Create Security and Data-Handling Problems

The main risk comes from inconsistent treatment across layers. A browser, application server, database, directory, or security filter may each interpret the same string differently, especially when one component normalises text and another does not. That can break equality checks, duplicate detection, allowlist logic, and username or hostname comparisons.

Combining marks can also produce lookalike strings that are visually close to ordinary text but not identical at the code-point level. That creates opportunities for confusion in identity lookup, file names, API parameters, and any control that depends on exact string comparison. The issue is broader than accents alone, because the same underlying mechanism affects many scripts and many forms of text processing.

Normalisation, Comparison, and Input Validation

Security-sensitive software should treat Unicode normalisation as a deliberate design choice, not an incidental library detail. If the system accepts user input, compares it to stored values, or uses it in access decisions, the comparison model needs to be explicit and consistent across all places where the string is stored, validated, displayed, and rechecked.

This is especially important when user-supplied text can flow into login fields, account identifiers, filenames, email-like identifiers, or policy-matching rules. A value that looks safe or duplicated may behave differently after normalisation, and a value that passes one validation step may fail later if another layer applies a different Unicode form.

Safe Handling Patterns for Unicode Text

Robust handling starts with defining a canonical string representation and using it consistently. Systems should validate input with awareness of Unicode composition, compare normalised forms where equality matters, and avoid assumptions that visible characters map neatly to individual code points. Security review should include the exact storage format, transport encoding, and any downstream transformations performed by frameworks or databases.

When text is used in security decisions, prefer explicit policy over implicit rendering behaviour. That means deciding how the application treats canonical equivalence, whether confusable text is allowed, and where normalisation occurs in the request path. The more places that independently “fix” text, the more chance there is of inconsistency.

Risk and Threat Considerations

Unicode combining characters can create denial of service for validation logic, identity confusion in user-facing systems, and policy bypass where one component sees a different string than another. They are most dangerous when a control depends on exact matching, but the application accepts multiple Unicode forms or does not normalise before making security decisions.

Failure mechanism: A string is validated, stored, or compared in one Unicode form, then later reinterpreted in another form, causing equality checks, allowlists, duplicate detection, or routing rules to produce the wrong result.

Impact: Attackers may be able to create confusing duplicates, bypass weak filters, poison logs or records with ambiguous values, or trigger mismatches between authentication, authorisation, and display layers.

Related resources from NHI Mgmt Group

• What breaks when invisible Unicode characters are not checked in code and AI rules files?
• What breaks in software supply chains when attackers hide malicious code with invisible Unicode characters?
• How should security teams detect malicious code hidden with invisible Unicode characters in Git repositories?
• Why do invisible Unicode characters create a security risk for LLM-driven development workflows?