Three types of third-party JavaScript deployment mechanisms
Third-party JavaScript tags can be deployed via three mechanisms: (1) Vendor JavaScript on page - the vendor provides JavaScript that the host embeds directly in the page HTML; (2) JavaScript Request to Vendor - the host page includes a few lines of code that request the JavaScript file directly from the vendor site on each page load; (3) Indirect request to Vendor through Tag Manager - the host requests JavaScript from a tag aggregator or tag manager site, which returns configured JavaScript files from multiple vendors based on host company settings.
Three major risks of third-party JavaScript execution
Invoking third-party JavaScript code requires consideration of three specific risks: (1) Loss of control over changes to the client application - new features may be pushed to third-party code at any time, potentially breaking interfaces and threatening application availability; (2) Execution of arbitrary code on client systems - third-party code is rarely reviewed before integration and executes with the same privileges as the user, similar to XSS attacks; (3) Disclosure of sensitive information to 3rd parties - browsers automatically include HTTP headers, originating IP, referrer data, and cookies when requesting third-party resources, exposing user data and enabling profiling across multiple organizations.
Server Direct Data Layer as secure third-party tag architecture
The Server Direct Data Layer is a secure technique for third-party JavaScript management. The host developers create a data layer consisting of either a DIV object with attribute values or JSON objects containing marketing and user behavior data. When specific events occur, a JavaScript event handler sends values only from the data layer to the tag manager server, which then sends data to third-party vendors. Only the host's first-party JavaScript executes on the user's browser, and only data the host explicitly decides on is sent to vendors. This approach is suitable for analytics tags but not for user interface tags that require DOM manipulation.
Subresource Integrity for third-party JavaScript verification
Subresource Integrity (SRI) ensures that only reviewed code is executed by adding integrity metadata to the script element. Example implementation: <script src="https://analytics.vendor.com/v1.1/script.js" integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk" crossorigin="anonymous"></script>. For SRI to work, the vendor host must have CORS (Cross-Origin Resource Sharing) enabled. It is important to monitor vendor JavaScript for changes regularly, as updates can result in secure but non-functional third-party code.
iframe sandboxing for third-party JavaScript isolation
Vendor JavaScript can be isolated using an iframe from a different domain, creating a 'jail' that prevents the vendor JavaScript from direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate via the postMessage mechanism. iframes can be further secured with the sandbox attribute. Example: <iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>. The sandbox iframe can validate message origin to ensure communication is from the expected source. For high-risk applications, combine iframe sandboxing with Content Security Policy (CSP).
iframe sandbox attribute example with postMessage validation
Example of sandboxed iframe with origin validation for third-party JavaScript isolation: The iframe page receives postMessage events and validates the origin: window.addEventListener("message", receiveMessage, false); function receiveMessage(event) { if (event.origin !== "https://somehost.com:443") { return; } else { // Initialize DOM and data for 3rd party code } }. This ensures only messages from the expected host origin are processed.
DOMPurify and MentalJS for sandboxing third-party content
Two tools can be used to sandbox and clean DOM data from third-party JavaScript: (1) DOMPurify - a fast, tolerant XSS sanitizer for HTML, MathML and SVG that works with secure defaults but offers configurability and hooks; (2) MentalJS - a JavaScript parser and sandbox that allow-lists JavaScript code by adding a '$' suffix to variables and accessors.
Data layer validation for third-party tag security
When using a data layer with third-party tags, the data layer can perform validation of values, especially those from DOM objects exposed to the user like URL parameters and input fields if required for marketing analysis. A corporate standard should require that tag JavaScript can only access values in the host data layer and can never directly access URL parameters or unvalidated user input. Host developers must agree with third-party vendors or tag managers on what attribute in the data layer will contain what value so vendors can create JavaScript to read those specific values.
Tag manager GUI access control requirements
For indirect requests to tag manager or aggregator sites with GUI configuration interfaces, the tag manager should implement technical controls such as restricting which JavaScript types can be deployed on a host site (disabling custom HTML tags and JavaScript code), and limiting JavaScript to accessing only data layer values. The host company should verify security practices including access controls to tag configuration for the host company, such as two-factor authentication.
Virtual iframe Containment for third-party tags
Virtual iframe Containment creates iFrames that run asynchronously in relation to the main page and provides containment JavaScript that automates dynamic implementation of protected iFrames based on marketing tag requirements. This is a technical control for preventing malicious JavaScript execution from third-party tags.
MarTechSec controls for third-party JavaScript risks
Marketing Technology Security (MarTechSec) refers to all aspects of reducing risk from marketing JavaScript. Controls include: (1) Contractual controls for risk reduction - contracts with MarTech companies should require evidence of code security and code integrity monitoring; (2) Contractual controls for risk transference - contracts can include penalties for serving malicious JavaScript; (3) Technical controls for malicious JavaScript execution prevention including Virtual Iframes; (4) Technical controls for malicious JavaScript identification such as Subresource Integrity; (5) Technical controls including client-side JavaScript malicious behavior in penetration testing requirements.
Most complete technical controls for third-party marketing tags
The most preventive technical controls for sites containing non-trivial marketing tags are: (1) A data layer that calls the marketing server or tag manager APIs, so that only the host's code executes on the page (inversion of control); (2) Subresource Integrity to ensure only reviewed code is executed; (3) Virtual frame Containment to prevent unauthorized JavaScript execution. These three controls combined provide the strongest protection against third-party tag-related security risks.
Vendor agreement security requirements for third-party JavaScript
Vendor agreements with third-party JavaScript providers should require evidence that vendors have implemented secure coding practices and general corporate server access security. In particular, agreements should address vendor monitoring and control of source code to prevent and detect malicious changes to JavaScript. This is essential given documented cases of JavaScript compromise after organization servers were compromised, such as Yahoo in January 2014.
Risks of tag manager GUI with user-controlled data sources
Allowing marketing teams to use tag manager GUI interfaces to specify where data is sourced can result in XSS vulnerabilities. Marketing users may retrieve data from unsafe sources like URL parameters and store it in a scriptable location on the page. This risk is mitigated by requiring all tag JavaScript to access only values from a host-defined data layer, not directly from URL parameters or user input.