Unicode Confusable Characters are different characters from one or more scripts that look alike in text, such as letters that resemble Latin characters. They are used in spoofing, phishing and identifier confusion, especially in domain names, usernames and source code, where visual similarity can hide a different underlying string.
What Unicode Confusable Characters Are
Unicode confusable characters are visually similar but distinct code points from one or more scripts. They matter because a string can look familiar to a person while actually containing different underlying characters, which creates confusion at the point of trust.
They are especially important in identity, naming, and security-sensitive text where humans inspect the string before a system fully interprets it. In practice, the danger is not that Unicode is broken, but that visual similarity can be exploited across scripts, fonts, and rendering environments.
Why Confusables Create Security Risk
Confusables are a classic enabler of spoofing and phishing because they can make a fake domain, username, file name, package, or code symbol appear legitimate at a glance. That is why lookalike attacks often pair visual deception with urgency, social engineering, or subtle differences in one character.
They are particularly dangerous in places where users rely on visual recognition rather than full parsing, such as browser address bars, chat messages, source code reviews, and registration workflows. The Typosquatting and Lookalike Domains Guide covers the broader attack patterns around homographs, punycode, defensive registration, and takeover response.
Where Confusable Characters Cause the Most Harm
The highest-risk environments are the ones that treat strings as identifiers or trust anchors. Domain names are the most obvious example, but the same problem appears in usernames, email local parts, code repositories, API names, package registries, certificate subjects, and configuration files.
Confusables can also undermine review and detection. A security team may miss a malicious lookalike during manual inspection, while automated controls may not flag the issue if they focus only on exact string equality rather than script mixing, unicode normalization, or visual similarity.
How Organisations Reduce Exposure
Defence starts with policy: define where non-ASCII characters are allowed, where they are restricted, and where mixed-script identifiers are prohibited. For public-facing names, many organisations choose conservative allowlists, normalization rules, and registration controls that reduce the chance of a deceptive lookalike reaching users.
Detection should combine inventory, monitoring, and review. Monitor newly registered domains, internal namespaces, code repositories, and package names for near matches; inspect suspicious strings in their normalized form; and use security review processes that treat homograph risk as part of naming governance, not just as an end-user phishing problem.
Operationally, the best outcome is clarity: users should not need to guess whether two strings are the same, and systems should not rely on human eyesight alone to decide. Where a high-value identifier must be readable and trustworthy, organisations should favour constraints that make deception harder rather than trusting visual inspection to catch it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | Unicode handling and normalization affect how user input is interpreted. |
| Recommendation — Normalize and validate identifier input before comparing or displaying it. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Input validation helps reject deceptive or malformed identifier strings before processing. |
| CM-7 — Least Functionality | Restricting allowable characters reduces attack surface in trusted naming paths. | |
| Recommendation — Validate character sets and normalization rules for security-sensitive text fields. Limit accepted scripts and symbols to the minimum needed for the business use case. | ||
| CIS Controls v8 | 5 — Account Management | Naming and account controls help reduce spoofing and lookalike account abuse. |
| Recommendation — Apply consistent naming rules and review processes for externally visible identities. | ||
| MITRE ATT&CK | T1566 — Phishing | Confusable characters are a common enabler for phishing and lookalike deception. |
| Recommendation — Hunt for lookalike indicators in phishing campaigns and user-facing trust surfaces. | ||
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?