logo

Understanding the security risks of third-party scripts

Third-party scripts are scripts that are developed externally and added to an organization’s website for various purposes. These scripts can have great benefits, but they can also introduce security risks for businesses.

Third-party scripts are added to an organization’s website by different teams for different purposes. Common categories of third-party scripts include:

  • Marketing: Marketing teams commonly add third-party scripts to websites to support and measure the success of their campaigns. This includes social media widgets, A/B testing services, and similar functionality.
  • Customer Service: Many corporate websites have things like a chatbot or interactive FAQ and support page, but the code for these aren’t written internally. Their functionality likely comes as a script from a third-party provider that is embedded in the website’s code.
  •  Regulatory Compliance: Data protection regulations like GDPR, CCPA, and others impose certain requirements on organizations. Some companies use embedded third-party scripts to help them comply with these requirements
  • Published: 21-11-2021

  • Related Category: Application Security

  • Type of Content: Articles

  • Owner: TrustedSite


All of these are worthy goals, and it makes sense that a company would use code developed by an organization that specialize in these areas to achieve them more efficiently. However, this means that a company’s website can end up containing a great deal of executable code that was developed by an outside party.

What are the security concerns of third-party scripts?

Using third-party scripts means you trust that the script’s developer hasn’t inserted malicious functionality into the code and has secured it against attackers trying to do the same. Unfortunately, this isn’t always the case so third-party scripts can pose significant security risks.

No developer visibility

Most development teams have strict rules on adding code to their codebase and managing potential errors. The trend toward DevOps and DevSecOps means that no code is added to the official codebase until it has been fully tested and proven to pass all functionality and security tests.

The use of third-party scripts undermines this process. Many third-party scripts are added by the marketing team using tag managers after code has exited the development pipeline. These tag managers pull code from a variety of different external locations and run it within the corporate website.

As a result, an organization’s website includes a massive amount of code that has not undergone testing and was likely added by employees with limited development and security knowledge. This creates a scenario where third-party add-ons can threaten the usability and security of the corporate website.

Unpatched Vulnerabilities

Unpatched vulnerabilities are one of the greatest threats to web security. The massive number of third-party libraries used in production code means that a developer only has visibility into a small fraction of the code used to implement their application. As a result, it’s difficult to ensure that external code does not contain unpatched and exploitable vulnerabilities.

The introduction of third-party scripts only expands this potential attack surface. With even more external code, which developers have no visibility into, the probability of an error sneaking in is even greater.

The fast-moving nature of marketing only makes this problem worse. The marketing team is unlikely to perform any testing before trying out a new script, and existing scripts may be left in place indefinitely and forgotten as long as they don’t break anything. As a result, the potential attack surface of an application continues to grow.

WordPress plugins are a great example of third-party scripts that commonly introduce vulnerabilities into a website. WordPress users include plugins in their pages to implement ecommerce functionality, perform analytics and similar actions. However, even the most popular WordPress plugins commonly contain vulnerabilities.

For example, in March 2021, two vulnerabilities were patched in the Facebook for WordPress plugin that enabled an attacker to run malicious code on a vulnerable WordPress page. These vulnerabilities affected over 500,000 WordPress pages and could lead to a major data breach or other security incident if exploited.

Supply Chain Attacks

While vulnerabilities can unintentionally creep into third-party code, cyber threat actors commonly take advantage of third-party scripts in their attacks. Injecting datastealing code or other malicious functionality into a single third-party script could enable an attacker to target many different websites with a single campaign.

The practice of injecting malicious functionality into websites and third-party scripts is such an effective attack vector that it became a signature of Magecart, a hacking group behind a series of cyberattack campaigns designed to inject web skimmers into ecommerce sites.

A web skimmer or digital skimmer is a malicious script that takes advantage of the rules regarding how data is shared between the various scripts running within a website. When credit or debit card information is entered into a site, a web skimmer will copy that data and send it to the attacker for use in fraudulent transactions.

The Magecart group used a variety of different techniques to inject web skimmers into ecommerce pages, including exploiting vulnerabilities and injecting malicious content into third-party scripts. One of their attacks, which targeted British Airways, led to the UK’s Information Commissioner’s Office assigning the largest GDPR penalty to date.

>> Download Article to continue reading.



Related Articles: