Published on February 25th, 2019
Written by Deepika Gajaria, Senior Director, Product Management


Today’s web sites integrate code and content from dozens of third-party service providers - user analytics, marketing tags, CDNs, third-party JavaScript libraries, and so on. Recent studies have found that almost 2/3rd of the content and code at websites is loaded from 3rd parties. A significant portion of this content comprises executable scripts with direct security impact on the website. What is worse, the way advertising works, these websites may not even be aware which servers are placing content on the website. In the absence of a proper vetting of third-party executable content, it can be potentially compromised or malicious. Many recent crypto-jacking attacks have transpired with a third-party library serving crypto-mining code to users from thousands of websites. Even the recent breach of user data on Delta, Sears and Best Buy sites was due to a compromised chat agent. Additionally, well known credit card skimmer group, Magecart is behind many external Javascript related hacks, notably including: British AirwaysNewegg and TicketMaster.

What is External (1st party, 3rd party..4th party) JavaScript?

To understand this, let's get back to the basics.

What is External JavaScript?

It's a JavaScript loaded in to the page via SCRIPT tag, and the content of the code is fetched from the location specified in the 'src' attribute:

<script src="LOCATION"></script>

The LOCATION attribute can be a:

  • Relative Path: It is used to load JS files from the same origin e.g /js/script.js
  • Absolute Path: e.g. hxxps:// 


1st Party/3rd party...4th party JavaScript?

It's commonly considered that 1st party JavaScript is the code that was written in-house, whereas 3rd party is the code that was written outside of the house. However, in order to really understand the security aspect of the breaches, let's use a different definition as explained next: 

1st party: JS loaded from the same location as the webpage (e.g. webpage: hxxps:// and JS url: hxxps:// )

3rd party: JS loaded from different location as the webpage is considered to be 3rd party (e.g. webpage: hxxps:// and JS url: hxxps:// )

3rd party JS can be further classified as:

  • Statically loaded: these scripts are part of the HTML source code of the webpage as sent by the server
  • Dynamically loaded (4th party): these script are loaded by statically loaded scripts during run-time

JavaScript and Website Security: The Root of the Problem

When a web page is loaded by the browser, the source (aka document) is rendered. As a result the browser exposes an interface called Document Object Model (DOM) that can be used to alter the document. This modification is done via JavaScript. The details of these concepts are beyond the scope of this blog, but we highly recommend going through these MDN links for a primer: 

This is the core of how today's dynamic and interactive web applications are built. This CRUD(create/read/update/delete)-like functionality is how JavaScript can access and manipulate the content of the HTML document. This is by far great as far the functionality is concerned.

The problem occurs when the JavaScript code (or the location where the code was built/hosted) is compromised (i.e. malicious code gets added to the existing code). This poses a very dangerous problem, especially when the web pages are serving sensitive content, or performing activities that can manipulate data (such as payments), because the malicious piece of JavaScript can perform malicious actions on it such as stealing username/passwords, credit card information etc. as it has been observed on the British Airways/Newegg/Ticketmaster hacks.

The following is a simple, crude version of an exploit that's similar to the BA/NegEgg hack:

  • html page loading an expected external JS script (1stOr3rdparty.js):
  • External JS: 1stOr3rdParty.js. This script, hypothetically, originally contained the functionality needed by the webpage. However, later on, it got compromised, and a malicious piece of JS was injected in to it as shown below. The malicious code tries to steal the data, namely the username and password, that the user submits from the original webpage.
  • This looks simple and straightforward - well, it is. The hardest part though is protecting against it.  

Revisiting 1st party/3rd party JavaScript:

The major question in all this is how did the code actually get compromised. To answer this, let's recall again that the external JavaScript is hosted at a location:

<script src="LOCATION/script.js"></script>

If the location's location is the same as where the script is hosted (e.g. British Airways and Newegg's case), there are a few scenarios:

  1. The location itself was hacked. i.e. in case of British Airways, it appears that, the location where the website hxxps:// is hosted was actually hacked.

Yes, a first party breach is very serious. While the attacker can do a lot more to compromise, infecting a JS is quite a sneaky way to steal customer data. 

2. The location where modernizr was pulled from was breached.

3. One more possible scenario involves XSS vulnerability (not associated with BA/Newegg/Ticketmaster).

What loads what....what?

The following scenarios depicts how complicated the system can get when 3rd party JS is loaded in to a webpage. Also, as an example and consideration, at the time of this blog, CNN's homepage loaded scripts from 39 different locations.

Now if any of these locations are breached, the attackers can embed malicious code in to existing code content.

Website Protection from external JavaScript Attacks

W3C/WebAppSec has been coming up with standards that are extremely useful in blocking external JavaScript attacks. Namely:

  • Sub-resource Integrity (SRI): This standard essentially lets web developers include a hash of the code that will be included when the script resource is fetched. If the specified hash does not match with calculated hash when the code is fetched, the script is not allowed to execute. This is a way for the developer to ensure that the entrusted code is ran. Example:
<script src=""

Note: SRI may not work well if there was a 1st party breach. 

  • Content Security Policy (CSP): This standard lets web developers generate a "whitelist" of locations from where resources can be loaded from (e.g. scripts, images), or locations where data can be sent to (e.g. forms, ajax etc). This is a great way to block any exploitation attempts against. Example policy (github):
Content-Security-Policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; connect-src 'self' wss://; font-src; form-action 'self'; frame-ancestors 'none'; frame-src; img-src 'self' data: *; manifest-src 'self'; media-src 'none'; script-src; style-src 'unsafe-inline'

Note: CSP may not work well with 1st party breach.

In addition to these standards, IFRAME isolation with sandbox is another technique that can be very powerful. This technique is explained here.

Website Security Challenges:

  • First party breaches can be tricky to handle because, by the nature of the attack, the attacker has finer control over the webpage content. The attacker can possibly change SRI hashes, as well as manipulate CSP policy. 
  • SRI hashes do not work in the following scenarios:
  1. If the end server where the script is server from, is not CORS enabled.
  2. If the code changes frequently or based on dynamic URL parameters.
  3. Hashes can only be enabled for scripts that are embedded by the developer of the website. However, enforcing SRI on scripts that are further loaded dynamically (4th party), won't be possible by the developer. As we saw earlier, external JS loading is a web in itself, and the developer cannot guarantee that all the actors would enforce SRI.
  • It is extremely challenging to constantly keep the policies up to date with ever so changing web application content. This definitely calls for a need for automation.
  • Malicious domain gets whitelisted in CSP: vetting 3rd party domains can be a tricky task. Despite a good vetting process, there's always a chance of a miss. If a malicious domain gets whitelisted, the attacks will be whitelisted too.


Web applications are increasingly vulnerable to JavaScript based attacks and we are seeing a significant uptick in third-party JavaScript based compromises. Enterprises should implement strict controls such as Content Security Policy (CSP), Subresource Integrity (SRI) and integrate these policies into the build process.

Contact us at with feedback on the blog or how we can help you.

Deepika Gajaria, Senior Director, Product Management

Deepika Gajaria, Senior Director, Product Management

Senior Director Product Management

Find Deepika on LinkedIn


Sign up for our Newsletter

Hand-picked security content for security professionals.