3rd Party Javascript Management Cheat Sheet



{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- Last revision (mm/dd/yy): // = Introduction =
 * valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

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

and what DOM objects it reads)

= 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 - Jim.Weiler@owasp.org