Last revision (mm/dd/yy): 02/26/2016

Introduction

TODO

3rd Party JavaScript Deployment Architectures

There are three basic deployment mechanisms for third party 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

A single line that invokes a javascript file, and that file calls lots of other javascript files from multiple vendors. The single line gets javascript from a tag aggregator or tag manager site. The actual content of that javascript (what other javascript files it calls and what DOM objects it reads) can be dynamically changed using a graphical user interface that non-technical users can work with, such as the marketing part of the business. This is the least 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 as soon as any javascript files are changed, 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