A Unicode homograph attack is a spoofing technique that uses visually similar characters from different writing systems to make one identifier look like another. It is used in domain names, user names and file names, where lookalike characters can trick people into trusting the wrong site or account unless systems apply normalisation, script checks and safe display rules.
How Unicode homograph attacks work
Unicode homograph attacks exploit the fact that many scripts contain characters that look almost identical in common fonts. An attacker can register or use a name that appears trustworthy at a glance, even though the underlying code points differ. The technique matters because the human eye often resolves the visible string before any system or browser comparison does.
In practice, the deception is strongest where users rely on quick visual judgement, such as links, login names, sender names, document paths, or file labels. The risk is not that Unicode is broken, but that mixed-script text can be rendered in a way that hides substitution unless software normalises, filters, or clearly displays the true identifier.
Where lookalike characters create exposure
The attack surface is broadest in identifiers that people copy, type, or trust without checking the underlying text. Domain names are the classic case, because a lookalike character can produce a domain that appears to belong to a known brand or service. Username spoofing and filename spoofing can create the same effect inside collaboration tools, email, storage systems, and developer workflows.
The practical danger is context loss. If the surrounding interface truncates text, suppresses punycode, or renders identical glyphs without warning, the user may never see the difference. That is why organisations should treat mixed-script identifiers as a trust problem as well as a display problem, especially when the identifier is used for access, routing, or user-facing verification.
NHIMG’s Phishing links guide is useful here because homograph attacks often succeed for the same reason phishing URLs do, the visible string looks safe before the underlying destination is checked.
Why browsers, mail clients, and platforms need defensive rules
Defence depends on constraining how potentially deceptive text is accepted and shown. Normalisation helps systems compare identifiers in a consistent form, while script checks reduce dangerous mixing of character sets that should not coexist in a single identifier. Safe display rules can also force clearer rendering, for example by showing punycode, warning on mixed scripts, or refusing registrations that combine visually confusable characters in risky ways.
These controls do not remove Unicode from the ecosystem. They reduce ambiguity so the interface does not silently convert a technical representation problem into a trust failure. The more the environment depends on humans to approve a name quickly, the more important those display and validation rules become.
Phishing Guide covers lookalike domains and homograph abuse in a wider deception context, which is useful because the same visual trick is often one part of a broader impersonation chain.
Checking exposure and limiting user error
Organisations should first identify where visually confusable names can be created, accepted, or displayed. That includes domain registration, internal naming policies, email gateways, chat systems, ticketing tools, code repositories, and file-sharing platforms. Exposure is highest where names are user-controlled and where the UI does not clearly distinguish scripts, encode the true character set, or preserve the full identifier.
User-facing controls matter too. Security teams should make suspicious-name review part of phishing defence, admin workflows, and support escalation, because the attack usually depends on a rushed approval decision. Even good technical filtering is weaker if staff are not trained to notice that a trusted-looking name may contain mixed scripts or confusable characters.
Risk and Threat Considerations
Unicode homograph attacks are dangerous because they exploit perception, not just protocol. A spoofed identifier can redirect trust, trigger credential capture, or cause users to hand over actions and approvals to the wrong party, especially when the display layer hides the difference between the fake and the real name.
Failure mechanism: A lookalike identifier is accepted or displayed without enough normalisation or script scrutiny, so the user sees a trustworthy string while the system resolves a different underlying value.
Impact: The result can be impersonation, unsafe clicks, account confusion, credential theft, or mistaken trust in a malicious site, user, or file.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Mixed-script display and identifier handling can expose spoofing through insecure presentation rules |
| Recommendation — Enforce strict normalization and rejection rules for confusable identifiers at the API boundary. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Homograph attacks exploit unvalidated, visually confusable input accepted as trustworthy text |
| Recommendation — Validate identifier inputs to reject unsafe mixed-script and confusable character combinations. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | Safe rendering and canonicalisation reduce spoofing from visually deceptive Unicode text |
| Recommendation — Canonicalize and sanitize user-controlled identifiers before display or comparison. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure application handling of names and links reduces spoofing opportunities from lookalike text |
| Recommendation — Review application input and rendering paths for confusable-character abuse. | ||
Practitioner Guidance
Why practitioners should care: Treat homograph resistance as a user-interface and input-validation requirement, not just an email or domain problem. If a platform allows free-form names, external sign-ins, or public-facing identifiers, it should make the true text unambiguous and make deception harder to scale.
What to watch for: Mixed-script labels, hidden punycode, truncated names, and identifiers that differ only by characters from another script deserve extra scrutiny. If a workflow depends on visual matching, add a deliberate verification step before trust is granted.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org