Things to Know (and Potential Dangers) with Third-Party Scripts
The following is a guest post by Yaphi Berhanu, who helps people learn JavaScript. Yaphi comes heading a warning: you should know what you’re getting into when you allow a third-party script on your site. You’re giving them some mighty powerful access, and there is plenty of proof that not all of them have your best interest in mind.
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.
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.
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:
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:
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?
Things to Know (and Potential Dangers) with Third-Party Scripts is a post from CSS-Tricks
