Things to Know (and Potential Dangers) with Third-Party Scripts

Share this:

The web is full of third-party scripts. Sites use them for ads, analytics, retargeting, and more. But this isn't always the whole story. Scripts can track your behavior, your preferences, and other information.

Here, we're going to look at the potential risks of these third-party scripts.

A third-party script might be a privacy concern

Third-party scripts can report back data that you weren't aware of.

Documentation from Google, Facebook, and Wikipedia, tells us directly that these scripts can track behavior, sites visited, purchase history, demographics, IP address, location, and more. That part is generally known.

Some of the data Facebook can track, according to their documentation.

While standard third-party tracking is generally documented, there may be tracking we don't know about.

For example, according to a study by researchers at Princeton and Stanford, 42% of the top sites (Alexa top 50 U.S.) present unique identifiers in plain text. That means eavesdroppers can track things like your email, username, full name, home address, purchases, location, history, IP address, and preferences. Just by clicking around the web, you can unknowingly allow someone to build up a huge profile of information about you. In fact, that same study discussed how the NSA piggybacked on some of Google's scripts to track people.

Here's a screenshot of an advertiser's official implementation guide that explicitly gives people code to transmit email addresses to them as unencrypted plain text. They encrypt each address after receiving it, but it still gets sent as plain text, so the damage is done.

Implementation guide allowing emails to be sent in plain text.

A third-party script might be a security concern

Any time you include someone else's external script on your page, there's an inherent security risk because that script has full access to the front end of your site.

Here are some examples of what these scripts have done.

Leaking credit card info through unsanitized data

Security researcher Randy Westergren discovered that many major tracking scripts don't sanitize data properly (thanks to my colleague Sam Ratcliffe for bringing this article to my attention). This allows attackers to inject any code they want, including code that can steal credit card numbers.

Here's a screenshot of malicious code getting injected into an unsanitized URL:

An attacker could have inserted any code.

What made the above screenshot particularly tricky is that the vulnerability didn't actually come from that script itself. Instead, it came from another third-party script's unsafe implementation of yet another third-party script.

I ran a test on an affected site to see this vulnerability for myself (don't worry; I didn't use a real card number), and it proved easy to extract sensitive info:

Many of the advertisers have since fixed the vulnerability, but that leaves open the question of what other exploits are still out there.

Exposing private data with non-HTTPS scripts

Many tracking scripts in the wild use regular non-secure HTTP. This can let attackers grab people's information, and it can cause security warnings that can scare away users on secure pages.

Here's an example of an implementation guide that uses HTTP on a secure cart page.

Code can change without you knowing

With third-party scripts, there's always the danger that the code can change or disappear without you knowing it.

My colleague Brent Kimmel told me about a technique called subresource integrity, which essentially lets you make sure you get what you expect. At the time of this writing, it hasn't gained full browser support yet, but keep your eyes open for it.

Also keep in mind that this technique works best when the original third-party script isn't flawed in the first place.

Third-party scripts often load other third-party scripts of their own

When the third-party scripts you trust bring in scripts you don't expect, this multiplies the potential for all of the security and privacy risks mentioned thus far.

Here's an example of a third-party script loading other scripts:

It's always a party when scripts bring their friends.

A third-party script might be a performance concern

Slower page loads

Third-party scripts frequently cause pages to load slower. For example, Business Insider's actual site loads in about 1 second, while third-party scripts account for the majority of the 7 to 15 seconds of load time. The following screenshot shows the tail end of a long line of third-party scripts numbering in the hundreds:

To their credit, Business Insider appears to load most of their third-party scripts asynchronously, so the perceived loading time doesn't take nearly as long as 7 to 15 seconds.

What happens when third-party scripts don't let you load them asynchronously?

Some scripts don't let themselves load asynchronously

When a script uses document.write, that prevents it from being loaded asynchronously. A lot of common third-party scripts use document.write, so they block the document and extend page load times unnecessarily.

Here's an example:

Some scripts affect scrolling performance

Third-party scripts often perform operations on the scroll event. Here's a screenshot of a script running a loop on every scroll.

While this example alone won't take down a site, it can contribute to a noticeable slowdown when multiple scripts are hammering the scroll event.

A third-party script might have unintended consequences

Third-party scripts can do all sorts of unexpected things to your pages. Here are a few.

Overwriting your variables

Some of the most widely used third-party scripts on the web use unnecessary global variables which can overwrite the variables on your site.

The following screenshot shows a script using two global variables to generate one random number (even using an unnecessary type conversion in the process).

Creating unnecessary risks by using eval

Since eval will run anything, it's a prime target for attackers. Here's an example of a tracking script with a function that uses eval on any arbitrary JavaScript. Interestingly enough, the function is actually called arbitraryJSCode.

While eval doesn't necessarily destroy everything in all cases, it does pose risks, so it at least warrants a second look when you see it.

Changing your layout

Some tracking scripts insert tiny images and iframes at the bottom or top of your page, which can create a gap above your header or below your footer.

The following screenshot shows a tracking tag creating a gap at the bottom of the Comcast/Xfinity site.

Alternatively, a third-party script can simply malfunction as in the following screenshot with some ad code on Elite Daily's site:

Setting you up for errors by tying functionality too closely to the DOM

The following example shows a tracking script whose functionality depends on specific DOM elements. A slight change to the site's layout can break this code.

Recap

Third-party scripts can provide powerful functionality, but they also bring risks to privacy, security, performance, and page behavior. Now that you've seen some of the risks of third-party scripts, you'll hopefully have an idea of what to expect when you encounter them.

If you have any questions, thoughts, or stories, feel free to leave a comment. It would be interesting to hear about people's thought process when integrating them. Do you avoid them all together? Do you only allow sources you highly trust? Do you use an intermediary like perhaps Google Tag Manager or Segment? Do you vet the code yourself by reading it or watching DevTools closely?

Share this:

Comments

I never understood why people actually load well-known libraries like jQuery or Prototype.js from google or any other content provider. They’re so simple to handle on your own server. Sharding and CDN might sound like good arguments, but only with the risk of additional points of failure.

Host as many of those libs on your own server(s).
Concatenate scripts into one single file (consider using grunt).
If your site uses many assets: Consider sharding. If the webserver has unused ressources you can simply add server names in DNS, forcing the browser to open more simultaneous connections to your server. Of course, this is redundant with http/2 or SPDY.
Consider self-written delayed script insertion:

I agree, and I personally prefer the idea of hosting libraries like jQuery on one’s own server. I’m sure there are other sides to this, but I’m with you that hosting it separately does introduce an additional point of failure.

As for the tracking scripts, some of them require direct interaction with the third-party servers, so that can complicate things and introduce a whole bunch of risks.

I remember having problems with certain browsers when not specifying the script type. Which ones I can’t remember right now; I used to try pads, mobiles etc. with such JS solutions. Maybe someone else can answer this?

The reason for using CDN’s for common libs like jQuery and such, is that your visitors have often ALREADY downloaded this script into their browser cache – thereby letting YOUR website load FASTER = better rank on Google in terms of mobile accessibility (time to download and render first page).

This comment thread is closed. If you have important information to share, please contact us.

Related

How do you stay up to date in this fast⁠-⁠moving industry?

A good start is to sign up for our weekly hand-written newsletter. We bring you the best articles and ideas from around the web, and what we think about them.

👋

CSS-Tricks* is created, written by, and maintained by Chris Coyier and a team of swell people. It is built on WordPress and powered up by Jetpack. It is made possible through sponsorships from products and services we like.