IDN homograph attacks: how a domain can look exactly like another

In April 2017 a developer named Xudong Zheng registered xn--80ak6aa92e.com and put up a page that said, in effect, “this is not Apple.” In Chrome 57, Firefox 52 and Opera, the address bar displayed it as apple.com — with a padlock. Nothing about the name looked wrong, because to a human reader nothing was. That is a homograph attack, and it is worth understanding properly, because the defences that work are not the ones most people reach for.

The short answer

A homograph attack registers a domain that renders identically to a real one by using characters from another script. Cyrillic а and Latin a are different characters with different code points, so аpple.com and apple.com are different domains that look the same. Browsers defend by showing you the raw xn-- encoding when a name looks suspicious, and the most reliable personal defence is a password manager, because it matches the real name rather than the rendering.

How the attack works

Domain names were originally restricted to ASCII letters, digits and the hyphen. Internationalised domain names let people register names in their own scripts — bücher.de, 日本語.jp, россия.рф — which DNS still carries as ASCII by encoding each label with Punycode and prefixing it with xn--. The browser decodes the label and shows you the readable version.

The problem is that Unicode contains many characters that look like Latin letters without being Latin letters. By Unicode's own confusables data, Cyrillic alone has domain-legal lookalikes for seventeen of the twenty-six: a, c, d, e, h, i, j, l, o, p, q, r, s, v, w, x and y. Greek, Armenian, Cherokee and others add more. Combine them carefully and you can spell a well-known brand name in characters that are, as far as DNS is concerned, completely unrelated to it.

A short history

• 2002. Evgeniy Gabrilovich and Alex Gontmakher describe the attack in “The Homograph Attack” in Communications of the ACM, demonstrating it by registering a microsoft.com spelled with Russian с and о.
• 2005. A Cyrillic-а spelling of paypal.com circulates, and ICANN issues a warning about homograph attacks. Browser vendors start restricting when they will display a domain in Unicode — at first by allowlisting TLDs, later by detecting labels that mix scripts.
• 2017. Zheng's xn--80ak6aa92e.com bypasses those mixed-script checks entirely, for a reason worth understanding — below. Chrome fixes it in version 58.

Why the 2017 version got through

By 2017 every major browser refused to render a label that mixed Latin and Cyrillic, so аpple.com — one Cyrillic letter among four Latin ones — showed up as xn--pple-43d.com. The check worked. Zheng's insight was that it only fired on mixing.

His label was аррӏе: Cyrillic а, two Cyrillic р, Cyrillic palochka ӏ, and Cyrillic е. Every character came from one script, so there was nothing mixed to detect. Every character also happened to have a Latin twin, so the whole label read as “apple.” This is called a whole-script confusable, and it defeats any defence that only asks “are these letters from the same alphabet?”

The third row is the reason the problem is hard. A rule that rejected every all-Cyrillic label would break the internet for a few hundred million Russian, Ukrainian, Bulgarian and Serbian speakers. The fix has to distinguish a Russian word from an English word spelled in Cyrillic.

How browsers decide what to show you

Chrome's policy, which it documents publicly, runs a series of checks on each label separately and falls back to the xn-- form if any of them trips. Among them: Latin, Cyrillic and Greek may not be mixed in one label; ASCII Latin may only be mixed with Chinese, Japanese or Korean; and — the 2017 fix — a label made entirely of letters from a whole-script-confusable set is shown as punycode unless the top-level domain is in that same script, or is one known to host many such domains.

That last clause is what keeps россия.рф readable while sending аррӏе.com to punycode. Under .рф, an all-Cyrillic label is the expected case and there is no ASCII brand for it to impersonate. Under .com, the same letters spell a name someone could register in plain ASCII.

The useful question is not “is this name foreign?” It is “does this name have an ASCII twin, and is that twin a different domain?” If the answer to both is yes, the name is a spoof regardless of which scripts it uses.

The defences that hold up

Use a password manager

This is the strongest personal defence and it works for a reason that is easy to miss. A password manager fills credentials by exact domain match, against the real underlying name, not against how the name renders. On аррӏе.com it looks for a saved login for xn--80ak6aa92e.com, finds nothing, and fills nothing. Chrome's IDN documentation lists it alongside Safe Browsing as a protection that does not depend on the display policy at all: password managers “won't automatically fill a password into a domain that is not the exactly correct one.” If yours suddenly offers nothing on a site you use daily, stop and look at the address.

Check the encoded form when it matters

Before entering anything sensitive on a domain you reached through a link, look at its xn-- form. A name that should be plain ASCII and has an xn-- form at all contains non-ASCII characters, full stop. The certificate details in your browser show the encoded name, and a punycode converter will show it too — ours reports which ASCII domain a lookalike impersonates and names each impostor character, so xn--80ak6aa92e.com comes back as “looks exactly like apple.com — but it is not.” It runs entirely in your browser, so a domain lifted from a phishing email never leaves your machine; if you would rather confirm that than take it on trust, here is how to check a web tool is not uploading your data.

Turn off Unicode display entirely, if you can

Firefox exposes this directly: set network.IDN_show_punycode to true in about:config and every internationalised domain is shown in its encoded form. It eliminates the attack, and it makes legitimate non-ASCII domains unreadable. If you only visit ASCII sites, that is a good trade.

Do not trust the padlock

The padlock says the connection to this domain is encrypted. It says nothing about whether this domain is the one you meant. Certificates for homograph domains are issued exactly like any other, because a homograph domain is a perfectly legitimate domain that belongs to someone else.

If you build software that handles names

The same attack works anywhere two strings can render alike: usernames, package names, display names, email addresses. The standard tooling is Unicode Technical Standard #39, which defines a skeleton for any string — every character replaced by its prototype lookalike — so that two names that would be confused share a skeleton. Comparing skeletons rather than raw strings catches аррӏе colliding with apple.

Compare hosts only after parsing them out of the URL with a real parser — https://apple.com@аррӏе.com/ is a URL whose host is the part after the @, which naive string matching gets backwards. Our URL parser shows how a conforming parser splits one.

Two details trip people up. First, apply the full normalisation pipeline before comparing anything; a decomposed accent and a precomposed one are different strings that render identically, which is its own variant of the problem — we measured how often domain converters get that wrong in most punycode converters disagree with your browser. Second, decide what to do about whole-script confusables deliberately, because rejecting every Cyrillic name is not an answer for a global user base.

A related trap: same name, different site

Homographs are two different names that look the same. There is also the opposite problem: one typed name that two browsers resolve differently. Four characters — German ß, Greek final ς, and the invisible zero-width joiner and non-joiner — were handled differently by the old and new IDNA standards. Firefox and Safari moved to the new behaviour in 2016; Chrome kept the old one until Chrome 110 in 2023. For seven years, typing faß.de opened one site in Chrome and a different one in Firefox. The full story is in the IDN glossary entry.

Takeaways

• A domain can be visually identical to another and still be a different domain owned by someone else.
• Mixed-script checks catch аpple.com but not аррӏе.com; the question that matters is whether a name has an ASCII twin.
• A password manager is the most dependable defence, because it matches the real name, not the rendering.
• The xn-- form never lies. When it matters, look at it.