I've just read an article about bitsquatting (which refers to the registration of a domain name one bit different than a popular domain) and I'm concerned about how it could allow an attacker to load its own assets on my website.

For example, if my website located at https://www.example.org/ loads a script file located at https://www.example.org/script.js, then an attacker could register dxample.org and host a malicious JS file, which would be downloaded and executed by some users of my website.

Is there any standard defense technique against it?

  • 70
    Typosquatting seems to be much bigger. And I for one don't think doublechick.net traffic was all bit errors!
    – Therac
    Commented May 8, 2018 at 12:14
  • 5
    I don't think you can do anything about it. In addition, it is difficult to draw a conclusion from the article you shown, as it is impossible to know whether those traffics are really bitsquat or just programming mistake from calling web page.
    – mootmoot
    Commented May 8, 2018 at 12:32
  • 7
    Is this a theoretical question, or are you genuinely concerned about your site? Are you running a popular domain, with millions of visitors?
    – Bergi
    Commented May 8, 2018 at 14:38
  • 1
    @Bergi: this is a theoretical question. I already worked on websites with millions of visitors, but there were bigger problems than bitsquatting since, as stated by some answers, it's a very rare event. :) Commented May 8, 2018 at 14:44
  • 4
    @Therac Typosquatting is a problem which makes phishing more likely to be successful, and is essentially an active attack. Bitsquatting seems to be a technique for taking advantage of normal, everyday errors in DNS resolvers, and is definitely a passive attack. Even a very careful user can fall victim to a "bitsquatted" domain because there is no opportunity to cross-check and intervene. Commented May 9, 2018 at 16:49

6 Answers 6


Is there any standard defense technique against it?

As outlined in the other answers, bit errors when querying domain names may not be a realistic threat to your web application. But assuming they are, then Subresource Integrity (SRI) helps.

With SRI you're specifying a hash of the resource you're loading in an integrity attribute, like so:

<script src="http://www.example.org/script.js"

From now on, it doesn't matter whether the script is fetched from a different domain due to a bit error (or modified by a MITM) because your browser will refuse to execute the script if the hash of its content doesn't match the integrity value. So when a bit error, or anything else, made the URL resolve to the attacker-controlled dxample.org instead, the only script they could successfully inject would be one matching the hash (that is, the script you intended to load anyway).

The main use case for SRI is fetching scripts and stylesheets from potentially untrusted CDNs, but it works on any scenario where you want to ensure that the requested resource is unmodified.

Note that SRI is limited to script and link for now, but support for other tags may come later:

Note: A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.

(From the specification)

(Also see this bug ticket)

  • 4
    According to MDN, SRI only works for <script> and <link> subresources. What about other subresources like images, frames, etc.? Commented May 8, 2018 at 12:39
  • 2
    @BenoitEsnard I don't know of any clever way to make that work for iframe or img, but it looks like they plan to extend SRI to other resource types soon (as I added to the answer).
    – Arminius
    Commented May 8, 2018 at 13:06
  • 3
    @BenoitEsnard eventually, you can load the image with javascript and check the signature.
    – Xavier59
    Commented May 8, 2018 at 13:32
  • 1
    You could load the images without waiting for the JS, and only display them once the JS loads. Commented May 8, 2018 at 19:14
  • 3
    @CandiedOrange Well, the main point is that flipping any single bit isn't sufficient to bypass SRI and inject a malicious script. Against a MITM threat, you'd obviously have to serve the original document over a secure channel (but not the script).
    – Arminius
    Commented May 9, 2018 at 11:04

Your concern is very likely unfounded.

First of all, you need to realize just how unlikely these memory malfunctions are. The person who wrote the above article logged requests to 32 clones of some of the most visited domains on the Internet over the course of 7 months. Those 52,317 hits had to be among hundreds of billions of requests. Unless you operate a website on the scale of Facebook, an attacker would have to be extremely lucky to even get just one unlucky victim on their bitsquatting domain.

Then you have to note that memory errors cause several malfunctions. The author writes:

These requests [...] show signs of several bit errors.

If the system of the victim is so broken that they can't even send a HTTP request without several bit errors, then any malware they download from it will likely not execute without errors either. It's a miracle it even managed to boot up in that condition.

And regarding those cases where bit errors were found in "web application caches, DNS resolvers, and a proxy server" and thus affecting multiple users (some of them maybe unlucky enough to get enough of the malware in an executable state): In these situations, the HTTP response would come from a different server than the client requested. So when you use HTTPS-only (which I assume you do, or you would have far more serious attacks to worry about), then their signature won't check out and the browser will not download that resource.

And besides, HTTPS will also make it much less likely to get a successful connection when there is a system with broken RAM on the route. A single bit-flip in a TLS encrypted message will prevent the hash from checking out, so the receiver will reject it.

tl;dr: stop worrying and set up HTTPS-only.

  • 11
    Quick lower bound math. 32 sites. Let's say 10M hits a day. Lets say each website's homepage loads 200 resources (sampled homepages for wikipedia, Amazon, and facebook). Let's say each month has 30 days. Seven months. That's 13 Trillion requests. That is 0.386% * 10^6 requests experience this or one in a quarter billion. So yeah, I'd not worry about this unless OP is CTO for Twitter. Neat exploit nonetheless.
    – Lan
    Commented May 8, 2018 at 14:40
  • 3
    @usr-local-ΕΨΗΕΛΩΝ Infrastructure problems are in the scope of the article. I quote: "While a bit-error in the memory of a PC or phone will only affect one user, a bit-error in a proxy, recursive DNS server, or a database cache may affect thousands of users. Bit-errors in web application caches, DNS resolvers, and a proxy server were all observed in my experiment. For instance, a bit error changing fbcdn.net to fbbdn.net led to more than a thousand Farmville players to make requests to my server.". It does not really matter for this attack where and how the bitflip occured.
    – Philipp
    Commented May 8, 2018 at 15:10
  • 5
    @Lan One in a quarter billion actually seems really high.
    – forest
    Commented May 9, 2018 at 2:37
  • 3
    @Philipp I'd expect the server gear to have ECC memory to avoid exactly this scenario Commented May 9, 2018 at 8:46
  • 1
    @ratchetfreak, while ECC can help, if your RAM is faulty it may be spitting out more error bits than the ECC can repair, even worse if it's your ECC chip itself that's faulty... However, the same argument applies, if the server even boots in this situation it'll be fairly unstable. Multi-bit errors that are too much for the ECC do occur, but at an even rarer rate than already noted. Commented May 10, 2018 at 16:58

I doubt about the article's dependability. While discussed at DEFCON and published as whitepaper, I have serious concerns about the experimental results.

According to comment by @mootmoot, the author failed to determine deterministic programming errors from random fluctuations of bits.

My concerning statement is

During the logging period [Sept. 2010 / May 2011, ndr] there were a total of 52,317 bitsquat requests from 12,949 unique IP addresses

No, the author only proved his squat domains were contacted, but likely failed to provide additional information

  1. What percentage of original CDN network does that traffic represent (this is verifiable in theory, but I don't have those figures)
  2. Occurrence of source referral domains

The second is very important because it helps isolate deterministic programming failures from random fluctuation of bits.

Consider the following example: if you find any entry to gbcdn.net (facebook squat) with referer https://facebook.com you likely have found a bitsquat.

If on the contrary you find multiple entries from a poorly known webiste which you can inspect to find with a broken like button, then the problem is probably due to a programmer not copying/pasting the code correctly, or even a bit flip occurred in the programmer's IDE. Who knows...

  • 2
    The author addressed point 2 by showing the fraction of source referral domains that were set at the original (the last figure on the page). Further, there was evidence of programmatic access to the bitsquat domains (Windows Update).
    – user71659
    Commented May 8, 2018 at 15:04
  • Underrated answer: the article’s conclusion is very obviously bogus. Things like “several bit errors per request” are a dead giveaway that these are not, in fact, bit errors but some other source of errors (or, as mentioned in another answer, seriously broken pieces of hardware). Other than that, bit errors virtually don’t happen. The other answers follow red herrings: this isn’t a real threat, there’s no need to defend against it. Commented May 11, 2018 at 14:32

Disclaimer: I'm an employee of Emaze Networks S.p.A.

One way to defend against this kind of attacks is to not allow attackers to register similar domain names.

To achieve this you can register many bitsquatted/typosquatted domains together with your main domain name, but this is impossible to do with all bitquatting/typosquatting cases, since they can be billions (consider also unicode etc!).

An alternative is to periodically monitor the domains registered, and if you find a suspicious domain you can check what it does and, if it seems to be a malicious site, you can report it to the registrar and ask them to pass the ownership of said domain to you.

We have a small service, called Precog that does this, by aggregating registrar information from different sources and running various kind of queries to detect bitsquatting/typosquatting/punycode-squatting domains: you can register your brand, put some keywords and we will contact you if a suspicious domain is registered.

Our tool takes into consideration 2nd level domains, obviously, but is also able to detect registration of many 3rd (or more) level domains, so we may be able to detect someone is going to use app1e.account.com to try and steal your apple credentials.

I must add: I believe the biggest use case for attacks of this kind is not to "get lucky" to receive a request because somebody mistyped the domain, but to use the domain as a phishing domain. So people will register the site àpple.com and send tons of emails that look like Apple's emails and try to get some people to insert their credentials/credit card information on their page.

  • 14
    àpple.com is not the result of bit-squatting, that's a different type of attack.
    – Barmar
    Commented May 8, 2018 at 19:14
  • @Barmar That seems like it is a vicious and undeserved attack on us poor souls that sometimes work in France, on those damn azerty keyeboards, but write only english... =(
    – Stian
    Commented May 9, 2018 at 11:03
  • 3
    @Barmar I don't see where I implied that àpple.com would be a bitsquatting attack. Bitsquatting attacks are just a subclass of the more general "similar-domain attacks". The only difference between bitsquatting and things like typosquatting is that bitsquatting might happen due to bit errors in the computer/network. However my answer provide an effective defense for all such attacks. If the attackers cannot own the bitsquatted domain, the bitsquatting attack cannot take place.
    – Bakuriu
    Commented May 9, 2018 at 16:22
  • 1
    Yeah, sorry about that. I was mostly reacting to your last paragraph. Bitsquatting is not likely to be used for phishing, since the resulting name doesn't look like the original. It's only useful for capturing traffic that was intended for the original domain.
    – Barmar
    Commented May 9, 2018 at 16:36
  • 1
    Registering all bitsquat domains requires is O(n) domain registrations, with n the length of domain name. You can multiply n by ~254 factor. We are assuming at most 1 character flips and 0x0 not allowed. Retain any illegal DNS char to find the correct figure. Commented May 10, 2018 at 13:19

Among all the answers, I am surprised I haven't seen a reference to Content Security Policy.

It is basically a one-stop solution for white-listing allowed sources of content. A simple fix would be to only allow JavaScript from your current domain (www.example.com) and block everything else.

  • I'm not sure how much this would help for bitsquatting. If a bit gets flipped somewhere in the network code while preparing a request for a resource, the CSP would still match OK because it gets checked before the request is started.
    – Wolfgang
    Commented May 11, 2018 at 19:00
  • Ah, it seems I didn't read into the question enough. Still, it can help by doing the same thing for IPs. Commented May 11, 2018 at 20:23

Arminius's answer is great. You can also use a strong Content Security Policy as another line of defense against bit-squatting.

CSP is an HTTP header that allows you to craft a fine-grained whitelist of URIs that your website can communicate with. For example, you can tell the browser that you'll only allow JavaScript to come from example.org/js/file1.js, only allow images from example.com/imgs, and fonts from example.net.

For a bit-squatting attack to be successful they'd need to flip a bit in the HTTP header AND in the request. If an attacker can flip only one bit then your website will throw a lot of errors - regardless of which bit is flipped.

You must log in to answer this question.

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