Homoglyph attacks explained
Characters that look identical and are not. Why they defeat human review, and why they are particularly effective against script allowlists.
TL;DR
Homoglyph attacks
WHAT IT IS
Using characters that render identically to legitimate ones, so a malicious domain or string looks correct to a human reader.
WHY IT WORKS
Unicode contains many characters that are visually indistinguishable in common fonts. A Cyrillic letter can look exactly like a Latin one.
WHERE IT BITES
Lookalike script domains that pass visual review, and allowlist entries that are not the domain you think they are.
Short on time? The defence is not looking harder. It is comparing by value rather than by appearance.
What is a homoglyph attack?
A homoglyph attack uses characters that render identically or near-identically to other characters in order to create a string that looks legitimate to a human but is a different value to a computer. The technique exploits the fact that Unicode contains many visually similar characters from different scripts. In most fonts a Cyrillic small letter a is indistinguishable from a Latin one, yet they are different code points and therefore different domains, different filenames and different allowlist entries. It is used in phishing, in typosquatting, and increasingly in script supply chains, where a lookalike CDN domain can pass a visual review that a real one would.
CSP is an origin allowlist. It decides where a script may load from, never what the script does once it is allowed. Both controls are useful, and they are not the same control.
How it is used against scripts
Three patterns worth recognising:
Lookalike script origin. A malicious script loaded from a domain that renders identically to a CDN you trust. A human reviewing the page source sees the expected name.
Poisoned allowlist entry. An attacker with access to your CSP or tag configuration adds an entry that looks like an approved origin and is not, so the policy permits their domain permanently.
Deceptive package or file names. The same trick applied to dependency names, so a review of a lockfile or a script filename reads as correct.
Why human review does not catch it
Because the whole point is that there is nothing to see. Reviewing a domain by looking at it is comparing rendered glyphs, and rendered glyphs are exactly what the attack makes identical. Reading more carefully does not help, and asking a colleague to double-check does not either.
Related: Punycode-encoded internationalised domains display as the decoded form in many contexts, which is convenient for legitimate users and useful for this attack.
Pinning the payload matters more than trusting the address.
What actually defeats it
Defence
Why it works
Compare by value, not appearance
Machine comparison of the exact byte sequence, which is immune to how it renders
Payload hashing
The origin becomes less important, because you are pinning the content rather than the address
Flag mixed-script identifiers
A domain mixing Latin and Cyrillic characters is almost never legitimate and is trivially detectable
Punycode display
Showing the encoded form in security review contexts makes the substitution visible
Treat new origins as new
Any origin not previously observed enters a review queue rather than being read and approved by eye
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
A useful distinction. A typosquat relies on a human making a typing mistake, so the domain is genuinely different and looks different. A homoglyph looks identical, so no mistake is required by the victim at all.
Yes, many are, through internationalised domain names. Registries and browsers have added mitigations, including displaying Punycode for suspicious mixed-script domains, and coverage is not complete.
Partly, and only if the policy is right. A CSP allows specific origins by exact value, so a lookalike domain is not permitted unless it was added to the policy. The risk is an attacker adding it to the policy, where it passes visual review.
Programmatically: check every entry for mixed-script characters and for any non-ASCII code point. Legitimate entries almost never contain them, so the false positive rate is very low.
Yes, substantially, because it shifts trust from the address to the content. If you pin the payload you approved, a script served from a lookalike domain is a payload you never approved.
Partly. Browsers apply heuristics and display Punycode for domains mixing scripts in suspicious ways. Coverage varies between browsers and versions, so it is a mitigation rather than a solution.
Yes, most commonly in phishing, and it appears in script supply chain incidents where a lookalike CDN domain is used to make injected code look routine to anyone reviewing the page.
Yes, in identifiers and string literals, which makes obfuscated code harder to read and can hide a destination inside otherwise ordinary-looking code.
Treat it as an incident. A homoglyph domain in your script origins or your CSP is not an accident, so preserve the evidence, establish when the entry was added and by whom, and check what loaded from it while it was there.
Yes, as part of 6.4.3. An inventory that records origins by eye can record the wrong origin. Comparing by value and pinning by payload hash is what makes the inventory trustworthy.
Related articles
Attacks
What is Magecart? Groups, methods and real incidents
Where the name came from, how the attacks work, and why they run for months undetected.
Attacks
What is web skimming? How card data leaves the browser
The technique, the exfiltration methods, and why your server logs show a successful checkout.
Attacks
What is formjacking? The mechanism, explained
How a script hijacks a form, the two main implementations, and what detects each one.
Attacks
Shadow code: the scripts nobody approved
Code executing on your pages that no one on your team chose, and how it gets there.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.