Last revision (mm/dd/yy): 04/7/2016

Introduction

TODO

3rd Party JavaScript Deployment Architectures

There are three basic deployment mechanisms for third party vendor javascript.

1. Vendor Javascript on page

This is where the vendor sends you the javascript and you put it on your page.

2. Server Direct

Javascript you write sends the data values to the vendor, or to a tag manager or tag aggregator site which then sends the data to vendors.

3. Javascript Request

There are two mechanisms to request javascript from a third party.

Direct from the vendor - This is where one or a few lines on the host page each request a javascript file or URL directly from the vendor site.

Indirect from a tag aggregator or tag mnager - This is where one or a few lines on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not the javascript vendor site. Each file or URL request returns lots of other javascript files from multiple vendors. What particular javascript is returned, and from what 3rd party vendor, depends on what the host site owner has configured the tag aggregator or tag manager to return for the requests made.

The actual content that is returned from the aggregator or manager (i.e. the javascript files and exactly what they do) can be dynamically changed by host site employees using a graphical user interface that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read by the 3rd party vendor javascript.

This is not secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript.

Standards

The standard says 'the tag js can only access values in the data layer that the server creates on the page. The js can never access a URL parameter'. The data layer is either 1. a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants. or 2. a set of JSON objects with the same data.

You have to agree with the 3rd party vendors what attribute in the data layer will have what value so they can create the js to read that value.

Tag manager/aggregator sites that offer the GUI to configure the js may also implement technical controls such as only allowing the js to access the data layer values, no other DOM element.

Letting the marketing folks decide where to get the data they want has resulted in XSS because they get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

Do it Yourself

Bringing this features all in house may not be feasible given the number of different 3rd (and 4th and 5th) party scripts used (sometimes more than 50) and the business functions they perform, and the speed with which the business needs to turn on, change and turn off various functions.

Vendor Agreements

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

Authors and Primary Editors

Jim Weiler - [email protected]

Other Cheatsheets