Third-party JavaScript - more critical than ever


The Syrian Electronic Army made the news several times lately by hacking popular news websites and making them display their propaganda messages. As with many similar hacks lately, the remarkable part was that the website wasn’t compromised directly. Instead a third-party service provider was hacked that the website used: Codero was used to compromise RSA Conference website, and Taboola to compromise Reuters website.

Why was it possible for Codero and Taboola widgets to completely take over the websites using them? That’s because these widgets were added to the webpage as third-party scripts which means that they got the same level of access to the webpage as its own scripts. They could alter text, spy on the user, steal login credentials, trick the user into installing malware and more. Of course, normally they wouldn’t do anything like this (ok, maybe spying) but the websites using these widgets made a bet on these scripts always behaving themselves — and lost.

The article on the Reuters compromise talks about 40 third parties that each Reuters web page trust this way. I found this statement hard to believe so I disabled Adblock Plus and opened a random Reuters article. I then copied the list of scripts from the list of blockable items in Adblock Plus, 134 entries not counting the scripts loaded by third-party frames! No wonder that page takes a while to load. A quick glance at the list immediately identifies most entries as not belonging to Reuters. What I’ve got there: AdNexus Media ads,,,,,, Akamai Content Delivery Network,, Amazon AWS Cloud Computing, Amazon CloudFront Content Delivery Network Audience Science tracking Bizo ads, CDNetworks Content Delivery Network cdnjs code hosting CloudFlare Content Delivery Network ads Criteo ads ensighten tracking Facebook widget Fastly Content Delivery Network Krux tracking, Google Adsense ads, Google Analytics tracking Google Loader code hosting Google Plus widget Google Tag Manager widget Grapeshot ads jQuery code hosting LimeLightNetworks Content Delivery Network LinkedIn widget, LinkSmart ads Lotame tracking Moat Analytics tracking Oracle BlueKai tracking PageFair ads tracking PerfectMarket widget QuantCast tracking Rubicon Project ads ScorecardResearch tracking Taboola widget Teads ads Twitter widget,, Verizon EdgeCast Content Delivery Network Vibrant Media ads YuMe ads

Hard to believe but that’s exactly 40 entries (35 if you don’t count various Google and Amazon services separately):

  • 12 ad networks
  • 10 tracking and analytics services
  • 7 widgets (mostly social networks)
  • 7 content delivery networks
  • 3 code hosting services (externally hosted JavaScript libraries)
  • 1 cloud computing platform

And there I was seven years ago thinking that was bad

Note that I might have misclassified one thing or another, particularly the distinction between ad networks and tracking services is often fluent. I also might have overlooked some other content delivery network involved. Why did I even put the content delivery networks on that list but not hosting providers for example? The important difference here is the scope: most high traffic services on the web use one out of a handful content delivery networks. This puts content delivery networks into a position where they can (and do) track users across most websites, a position that is comparable to Google’s. Also, a compromised content delivery network would become a disaster for countless websites, even if these don’t use the content delivery network directly.

Altogether that’s 40 parties that can track each visitor to the Reuters website, 40 parties that this website has to trust and 40 parties that a hacker can choose from to compromise it. Finding one weak link shouldn’t be hard then. So that’s where we are now, six years after my first article on this topic – most websites can be compromised with comparably little effort due to numerous dependencies on external parties. And too often it isn’t merely a nasty message, instead the websites start infecting their visitors with malware.

How do you protect yourself? My favorite solution is naturally Adblock Plus. With the default settings it already blocks half of the scripts on the Reuters website. You can go further by enabling the privacy protection feature on the first-run page (will add EasyPrivacy filter list, can also be done here) – this will leave you with “merely” 46 scripts (around 10 third parties), without any functionality loss whatsoever.

The most radical solution is blocking third-party scripts altogether via *$script,third-party filter as I suggested six years ago. Unfortunately, this is only something for experienced Adblock Plus users who are willing to tweak their filters regularly to make websites work again. The main problem here are content delivery networks that use a different domain name to deliver essential website content. So you would have to regularly add exception rules like @@||^$script, for these cases.



  1. Al

    I found a great tool for blocking/allowing cross site requests in RequestPolicy. It allows you to either use whitelist or blacklist mode (with whitelist mode breaking many websites) and it does this in an easy to use interface. No need for cryptic rules like in your article!

    There is also beta version 1.0 on RequestPolicy website with improved interface.

  2. Nindroid

    It’s really quite unnerving to know the level of access those scripts have to our data. Isn’t anybody like Mozilla worried about this or making moves to prevent this kinds of behaviour?

  3. geeknik

    I thought Mozilla was going to start blocking 3rd party cookies by default last year, but it looks like someone or something changed their minds:

    I use Firefox Nighty w/ AdBlock Plus and I have 3rd party cookies disabled unless I’ve visited the site before. Knocks out quite a few of those tracking cookies.

    Reply from Wladimir Palant:

    Disallowing cookies doesn’t completely disable tracking, and it certainly doesn’t mitigate any of these security risks unfortunately.

  4. Šime Vidas

    Isn’t there a Web Platform tech that helps with security when loading third party script onto webpages?

    Reply from Wladimir Palant:

    As far as I know, you can only sandbox frames but not scripts. Any mechanism restricting what third-party scripts can do would be big news to me. Content Security Policies don’t really help here either.

Commenting has expired for this article.

← Older Newer →