I've seen people in security saying URLs with Cyrillic characters are dangerous. If you ever type such characters on a browser you'd see they break into crazy unrecognizable URLs that have nothing to do with the original name.

Another attack would be to put them into the href HTML tag and another website in the link, but you don't need Cyrillic characters for that, just put the original name.

Is there a case where such characters are really a threat?

  • 20
    "If you ever type such characters on a browser you'd see they break into crazy unrecognizable URLs that have nothing to do with the original name." -- example? Are you sure it isn't simply encoding the characters?
    – schroeder
    Commented Mar 13 at 11:12
  • 5
  • 3
    Cyrillic characters could be a thread in the sense that users may wrongly think they have fallen victim to Russian hackers, and in reaction switch to a system that actually is less secure... Commented Mar 14 at 14:23
  • How or why might breaking into crazy unrecognizable URLs that have nothing to do with the original name be any kind of threat? Isn't the reverse more likely… that the simple act of breaking into anything unrecognizable makes the process noit less but much more secure? Commented Mar 19 at 20:26

6 Answers 6


Cyrillic characters by themselves are not a threat. There are whole nations which use these characters without additional risks.

The problem is when characters look similar to others, since these then can be used in social engineering to trick users into seeing something else than what's actually there. i.e. "example" vs. "exаmple", where the "a" (U+0061) is replaced by similar or even identical looking cyrillic "а" (U+0430). These kind of attacks are called homograph attacks. This can for example be used in domains names - see IDN homograph attack. But it can also be used in other places like for sender names in an email, in the email text to bypass spam filters etc. Such homograph attacks are not restricted to cyrillic characters.

  • 12
    In case people cannot see the difference, the first a is just standard a, ascii character 61, but the second one is actually a two-byte character that literally looks exactly the same, but has hex code of 0xd0 0xb0
    – Nelson
    Commented Mar 13 at 13:39
  • 32
    @EvilSnack: I'm not sure exactly what you mean but it sounds like you haven't thought that through. You can't remap anything based on "intent" because intent is not an input parameter you have access to. Commented Mar 13 at 15:52
  • 6
    It's kind of uniquely problematic with cyrillic and domain names due to enough homographs existing to make one of all cyrillic characters for quite a few important US company names and thus not trip the homeograph attack detector.
    – Joshua
    Commented Mar 13 at 16:30
  • 17
    @EvilSnack That could then create a homograph attack in the other direction. Now Ukrainian users will get sent to the wrong place when they try to visit приклад.com because the Cyrillic а got mapped to an ASCII a. You can't just say it applies in all cases, because domain names containing Cyrillic characters have already been registered; it's too late to implement a rule that all homoglyphs have to be normalized to ASCII in domain names. Commented Mar 13 at 22:05
  • 8
    @EvilSnack: "People with some languages have to register the wrong characters in their domain because my language is more important" is not a defensible policy. It's a non-starter. Commented Mar 14 at 14:14

As you say, most browsers will display punycode URLs, so that something like http://exаmple.org will be displayed as http://xn--exmple-4nf.org.

However, there are cases where an attacker may be able to include a URL, but does not have control over the HTML, so they can't just hide the true destination with the href text.

For instance, many messaging sites/application will convert things that look like links (such as http://exаmple.org or www.example.org) into actual hyperlinks without giving you the option to specify where the link points. And so do many website, including StackExchange - it automatically made the following text into hyperlink - http://www.exаmple.org.

So there can still be some value to homograph attacks in those cases, especially if users trust that the URL they see is where the link will point, because the application doesn't allow you to change that. This can also be more effective on mobile apps, as you can't always see the real destination of a link (due to the lack of mouseover)


I've seen people in security saying URLs with Cyrillic characters are dangerous.

Users are often told, to check URLs before clicking on them and/or before entering sensitive information. If an email purporting to come from mybank has a link to mybank.com, then it's probably ok to follow that link. If it has a link to evilsite.cn then the user should probably not follow it. Thus attackers look for ways to make URLs that look legitimate, but are not.

Some characters are logically distinct but rendered in a manner that is difficult or even impossible to distinguish from each other. Even in ASCII this can be a problem, 1 (digit 1) can look similar (or even identical) to l (lowercase letter l). 0 (digit zero) can look similar or identical to O (capital letter O).

However, within ASCII hostnames such opportunities were quite limited for two reasons.

Firstly the way the browsers displayed URLs tended to make the distinctions between o and 0 and l and 1 more distinct than they might otherwise be. Browsers tended to display URLs in lower case, so there was a clear visual distinction between 0 and o and they tended to use proportional fonts where 1 and l had substantially different widths.

Secondly the number of available substitutions was quite small. For example substituting 0 for o and 1 for l in google gives only 8 permutations. Easily a small enough number for google to register them all.

Adding internationalisation to hostnames made the problem worse in two ways.

  1. Each additional letter that an attacker can substitute, doubles the number of domains that the defender must potentially keep control of to avoid homoglyph attacks on the name.
  2. Some characters from the Cyrillic alphabet (and to a lesser extent the Greek alphabet) look literally identical to Latin letters when rendered in most common fonts.

If you ever type such characters on a browser you'd see they break into crazy unrecognizable URLs that have nothing to do with the original name.

What you are seeing there is the browsers mitigation against the attack.

To maintain compatibility with existing infrastructure, internationalised domain names were/are implemented by encoding the unicode strings into ASCII ones using a process known as punycode.

When your browser sees an internationalised domain name string that it deems suspicious, it displays the encoded punycode string instead of the internationalised string. Firefox's algorithm for this is documented at https://wiki.mozilla.org/IDN_Display_Algorithm

These threats are not unique to domain names, they come up anywhere where Unicode characters are used as user-supplied identifiers. If you are designing a system with user supplied identifiers you should think very carefully about what characters you will allow. Taking into account both technical and human factors.

Another mitigation you will see in browsers against confusing URLs is to highlight the part of the hostname that is allocated by a public registery in a darker colour. This helps mitigate against stuff like mybank.com.some.long.and.meaningless.string.example.com/another/long/and/meaningless/string where the operator of the site is burried in the middle of the URL.

  • 4
    "If an email purporting to come from mybank has a link to mybank.com, then it's probably ok to follow that link." — I would say it's not O.K. because, as far as I know, an e-mail can be made to appear as if it came from my bank, but in fact, it's not coming from my bank. And if that's possible, then the link pointing "back to the bank" can contain that homograph attack that Steffen Ulrich's answer describes, and that's exactly how they get you. That's exactly how phishing works, they spoof the origin of the e-mail, and lead you to their site.
    – Levente
    Commented Mar 14 at 21:03

The "threat" is not due to Cyrillic characters, but due to mixing confusable characters, which are often characters from different character sets. Mixing Cyrillic into Latin has exactly the same threat level as the other way around.

It's not limited to Cyrillic. Many Unicode characters have "confusables", meaning other characters that look similar. With this web tool at unicode.org one can get a complete listing of official confusables. How similar they look exactly depends on your font.

Listing for a:

𝝰 a a 𝑎 𝗮 𝕒 𝖆 𝓪 𝚊 𝞪 а ɑ α 𝔞 𝒂 𝘢 𝛂 ⍺ 𝒶 𝙖 𝜶 𝛼 𝐚 𝖺

Or for o:

𝘰 ం ಂ ം ං օ 𝐨 𑣗 𝔬 ᴏ ᴑ 𞹤 𐓪 𝚘 𑣈 ဝ ⲟ 𝛐 ഠ 𝛔 ﮦ ﮧ 𝗈 𝝈 ﮨ ﮩ ﮪ ﮫ ﮬ ﮭ 𞺄 ℴ 𝝄 𝞸 𝞼 ꬽ о ο ၀ σ o ๐ ໐ 𝕠 𐐬 𞸤 𝙤 𝑜 𝒐 ס 𝜎 𝖔 ० ੦ ૦ ௦ ౦ ೦ ൦ ﻩ ﻪ ﻫ ﻬ 𝜊 o 𝝾 𝞂 𝓸 𝗼 ჿ

Or for i:

𝓲 𝞲 ꙇ ⅈ i 𝔦 𝘪 ӏ 𝙞 𝚤 𝐢 і 𝑖 ˛ 𝕚 𝖎 Ꭵ 𝚒 𑣃 i ɩ ɪ 𝒊 𝛊 ⅰ ı 𝒾 𝜾 ⍳ 𝜄 ꭵ 𝗂 𝝸 ℹ ι 𝗶 ͺ

Note that typosquatting works even within a single character set. In this attack on Python infrastructure, a compromised GitHub account committed a link to pythanhosted.org buried between many legitimate pythonhosted.org links. So enforcing ASCII (which would discriminate against most non-English languages) doesn't even fully solve the problem.

NB: Due to technical limitations, Stack Exchange did not let me post all confusable characters.

  • 1
    Firefox has an actual defense against almost all of these. The only way to bypass the defense is to use characters from a single alphabet; and the only single alphabet that can match a Latin alphabet well enough to attack is Cyrillic. (Unless of course you've got one of those handful of single letter domains left. Thus Elon Musk set up his own downside.)
    – Joshua
    Commented Mar 15 at 18:53
  • @Joshua Maybe Mr. Musk has registered all the single letter domains for confusables with the letter X or x. At least with single-letter domains the number of permutations is fairly small, and Mr. Musk has deep pockets.
    – gerrit
    Commented Mar 28 at 16:12

An attacker may be able to trick you into visiting their website instead of the one you wanted to visit. Https doesn’t help, because the fake website will have a genuine certificate for their fake website.


I've seen people in security saying URLs with Cyrillic characters are dangerous.

As other answers on this page point out, the thing that's dangerous is not URLs with Cyrillic characters, it's different URLs that look the same, but are actually different.

If you ever type such characters on a browser you'd see they break into crazy unrecognizable URLs that have nothing to do with the original name.

The only reason this happens is because browsers have implemented features specifically to mitigate this risk. In other words, it's a bit like saying "the rain isn't wet because I have an umbrella".

The original intent of Internationalized Domain Names (IDN) is that the user would never see the "crazy unrecognizable" form of the URL, they would see a URL in their language. A Russian website can use a Cyrillic domain name, a Japanese website can use a domain name with Kanji and Hiragana, and so on.

However, people spotted that the huge range of characters in Unicode includes a lot of letters which look the same, but are not. To take the example from the Wikipedia page on IDN homograph attacks, it's impossible in many cases to see the difference between "wikipediа.org" and "wikipedia.org" - where one has substituted a Cyrillic letter for the "a".

Browsers try to protect against this attack by detecting "unlikely" combinations in a URL - in the example above, the fact that Latin and Cyrillic letters are mixed looks suspicious, so browsers change the address bar to xn--wikipiedi-8yh.org This isn't "nothing to do with the original name"; it's the encoding used to represent the name in the DNS system, which only allows ASCII characters; but it's visually very different, so the user is likely to immediately spot something is wrong.

This doesn't mean Cyrillic URLs always look that way. Go to https://xn--80a.example.com and you will see the opposite happens: the browser translates the encoded URL into the Cyrillic form, and your address bar will show "а.example.com" which probably looks exactly like "a.example.com", but is a completely different address.

That means the attack is still possible: find a Cyrillic URL which doesn't look "suspicious" according to the rules defined by the browser, but still fools the user into thinking they're going to a legitimate site, when they're actually going to your phishing page.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .