How To Vet and Manage The Behavior of Third-Party Scripts in Your Website

Vetting and managing the behavior of third-party scripts on your website allows you to avoid websites sinking with third-party scripts. Also, the third-party JavaScript management Cheat Sheet is especially relevant when we are talking about the development of software products, namely web applications.

The use of third-party code has become the norm, contributing to an overall acceleration of the development lifecycle.

What are the impacts of this third-party code on application security?

We explore the current state of web application development, the associated security risks, and how to vet and manage third-party scripts on your website.

The Current State of Web App Development

The current demanding and dynamic market puts added pressure on development teams to deliver products faster.

To keep up with this pace, teams have to shorten the development lifecycle of web apps, which ends up raising concerns on the topic of application security.

To understand the core of the security concerns, we first need to understand that to fasten the development lifecycle, teams rely on various third-party scripts, frameworks, and libraries.

70% of the code in the average web app is sourced from third parties. And with 35 third-party components and 31 fourth-party components on average, it’s no wonder that the typical web application contains a huge mashup of client-side code (as illustrated below).

But why does this result in a larger attack surface?
When development teams use externally sourced pieces of code, they are inherently trusting this third-party code, along with any fourth-party code that it uses, and so on.

Companies end up having a long chain of code dependencies without really having good visibility over what they are effectively running and what each piece of code is actually doing.

The risks of the lack of visibility over third-party code

The main problem with lacking visibility and control over third-party code is that third-party scripts have the same privileges as all the code that is developed internally. This means a third-party chat plugin can start interfering with a payment form (which is precisely what happened in the Ticketmaster/Inbenta Magecart attack of 2018).

Because the typical modern web app today has a lot of sensitive data passing through on the client side, all that sensitive data is at risk of being leaked by a rogue third-party script.

When an attacker manages to breach the provider of a third-party script, companies that are using that script have no visibility that the attack is even happening.

Web application firewalls and other network defenses consistently fail to detect the attack because it originates from a source that’s trusted by default.

Attackers have a window to exfiltrate any data collected and send it to a drop server under their control. In the case of Magecart web skimming attacks, research shows that they have risen by 20% during the pandemic and remain active for 22 days on average before being detected and removed.

Consequences of a Third-party Script-based Attack

With the development of strict regulations like GDPR and CCPA, the leakage of sensitive user data into the hands of attackers is a clear violation of users’ privacy rights. When it comes to payment data, this can also mean a breach of compliance with PCI DSS.

Breaching compliance with any of these regulations results in financial costs due to the payment of hefty fines.

Magecart attacks are well-known third-party-based attacks since they have resulted in some of the highest fines seen in the scope of compliance with security and privacy regulations.

Apart from the direct breach of compliance, it is important to be aware of the damage to the company’s reputation, which can result in business losses and leave a permanent dent in its relationship with customers.

Vetting and Managing the Behavior of Third-party Scripts

First, you must gain visibility into which third-party scripts are running on the website and what types of actions they are performing (i.e., their behavior).

We provide a free website inventory report that gives a snapshot of these scripts and their behavior, broken down into actionable insights.

The report starts by detailing the number of domains that are receiving data from the website and how many of these are third-party.

It also analyzes the assets that are loaded on the website, including the number of assets coming from third parties and how many different domains are loading these assets.

Another key detail is the number of poisoning events detected on forms and on network events, as these may indicate that third-party scripts are collecting data from forms or intercepting network data (data leakage).

The report also presents high-level tables displaying critical client-side security threats, such as the one below.

The report includes other tables and graphs with detailed information on specific detections, such as:

• Code or native API poisoning

• Source domains

• Destination domains

• Resources and scripts

• Breakdown of scripts into first- and third-party

• A digested overview of the critical issues.
  

All this information allows for vetting the behavior of third-party scripts and is an important step toward reducing the website’s attack surface.

Request your own free website inventory report today!