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.

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 data-stealing 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.

How to mitigate the risks of third-party scripts

Though they can pose significant risks, the benefits of third-party scripts can outweigh the risks if they are managed appropriately.

Perform regular vulnerability and security scans

Exploitable vulnerabilities or malicious code could be introduced into a website in a variety of different ways. Since third-party scripts typically sit outside of the development pipeline, they are not even checked for vulnerabilities as part of the development process.

Because the complete set of potential vulnerabilities in a website is only visible in the production site, an organization should regularly inspect their websites for vulnerable and malicious code.  This can be accomplished using a vulnerability scanner which will look for known vulnerabilities and other suspicious code within a website. Vulnerability scans against a site can even be automated, making it possible to run them on a frequent basis to ensure that the organization has full visibility into potential security risks.

Keep an eye on the internet activity of your website

Malicious third-party scripts are designed to do a number of different things. However, most of these types of attacks require the ability to communicate with their controller to receive commands or send data back.

Monitoring the HTTP requests made by the company website can help with detecting the presence of malicious third-party scripts on a company’s webpage. If the website starts connecting to a new domain or a suspicious-looking one, this may be an indication that something serious has changed in the code and that further investigation is warranted.

Regularly perform site content audits

Third-party scripts are easy to add to an organization’s website, but getting rid of them might not be as easy. The team responsible for a particular script may eventually forget about it, leaving it running on the site even after it’s no longer being used.

Performing regular site content audits can help to manage the risks associated with third-party scripts. By considering whether a particular third-party script’s value to the organization outweighs its associated risks, and removing it if it doesn’t, a company can ensure that its websites only include necessary and useful code and functionality.

Monitor for changes in your third-party scripts with Halo Security

Monitoring the set of scripts running on an organization’s website can be difficult without the proper tools. Halo Security’s Website Monitoring service provides deep visibility into the scripts that are running in an organization’s website, including information about their sources, relative risk, and how they have changed over time. This information makes it easier to pinpoint potentially suspicious or malicious scripts that require further investigation or potential removal from an organization’s site.

In conclusion

When an organization uses third-party scripts, it accepts a significant amount of cybersecurity risk. Many organizations are unaware of this fact, and the teams most responsible for managing the company’s cyber risk have little or no visibility into the process.

For this reason, managing the cybersecurity risk of third-party scripts requires an organization to first find out what third-party scripts are currently running in their environment and assess the risk that these pose to the company. From there, an organization can take action to manage this risk and develop processes and procedures that will help to minimize the risk of third-party scripts in the future.

Monitor and manage the risk of third-party scripts on your site with Halo Security's attack surface management solution.

Editor's note (August 2022): This article was originally posted on the TrustedSite blog in May 2021. It has been updated for the Halo Security blog.