DOMPurify for XSS sanitization
DOMPurify is a fast, tolerant XSS sanitizer for HTML, MathML and SVG that works with a secure default while offering configurability and hooks for customization.
OWASP Cheat Sheets · all subjects
third-party javascript security
19 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Major risks from third-party JavaScript tags
The three primary risks of invoking third-party JavaScript code in web applications are: (1) loss of control over changes to the client application, where code hosted at third-party servers may change at any time without guarantee of stability, potentially breaking interfaces and exposing availability; (2) execution of arbitrary code on client systems, where third-party code receives the same privileges as the user and is rarely reviewed before integration, similar to XSS attacks; (3) disclosure of sensitive information to third parties, where the browser directly contacts third-party servers with HTTP headers, originating IP, referrer, and cookies, potentially revealing user identity and behavior across multiple websites.
Three deployment architectures for third-party JavaScript tags
Third-party JavaScript tags can be deployed through three basic mechanisms: (1) Vendor JavaScript on page, where the host embeds JavaScript directly in the HTML page; (2) JavaScript Request to Vendor, where the host includes script tags that request files directly from the vendor site on each page load; (3) Indirect request to Vendor through Tag Manager, where script tags request files from a tag aggregator or tag manager, which returns configured JavaScript files from multiple vendors.
Subresource Integrity for third-party scripts
Subresource Integrity (SRI) ensures that only reviewed code is executed by generating integrity metadata for vendor JavaScript and adding it to the script element with an integrity attribute containing a hash (e.g., sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk) and crossorigin="anonymous" attribute. SRI requires the vendor host to have CORS enabled. Regular monitoring of vendor JavaScript for changes is recommended because updated vendor code may become secure but non-functional.
Server Direct Data Layer for secure tag management
The server direct data layer is a secure technique where the tag manager developer interface generates JavaScript that accesses only data from a host-defined data layer, which can be either a DIV object with attribute values or JSON objects containing marketing or user behavior data. Only first-party code executes on the user's browser: first to populate the data layer on page load, then event handler JavaScript sends only the data the host chooses from the data layer to third parties. This requires host developers to work with vendors to determine required data types, with the tag manager to agree on data transmission protocols, and with vendors to agree on receiving protocols. Validation of data layer values can be performed, especially for user-exposed values like URL parameters and input fields.
Server direct data layer limitations
User interface tags cannot be made secure using the data layer architecture because their function is to change the user interface on the client, not just send data about user actions. However, analytics tags can be made secure using the data layer architecture because they only need to send data from the data layer to third parties without requiring UI modifications.
Sandboxing third-party JavaScript with iframe
Third-party JavaScript can be placed into an iframe from a different domain (e.g., static data host) to act as a jail, preventing the vendor JavaScript from having direct access to the host page DOM and cookies. The host main page and sandbox iframe communicate via the postMessage mechanism. iframes can be secured with the iframe sandbox attribute, and for high-risk applications, Content Security Policy (CSP) should be used in addition to iframe sandboxing.
MentalJS JavaScript sandbox
MentalJS is a JavaScript parser and sandbox that allow-lists JavaScript code by adding a dollar sign suffix to variables and accessors.
Virtual iframe containment for tags
Virtual iframe containment creates iFrames that run asynchronously in relation to the main page and provides containment JavaScript that automates the dynamic implementation of protected iFrames based on marketing tag requirements.
RetireJS tool for vulnerable JavaScript libraries
RetireJS is a free open source tool that identifies JavaScript libraries with known vulnerabilities. Keeping JavaScript libraries updated is necessary to prevent vulnerability exploitation, as older versions can have known vulnerabilities leading to XSS.
MarTechSec controls for marketing JavaScript risk
Marketing Technology Security (MarTechSec) controls include: (1) Contractual controls for risk reduction requiring evidence of code security and code integrity monitoring; (2) Contractual controls for risk transference including penalties for serving malicious JavaScript; (3) Technical controls for malicious JavaScript execution prevention such as Virtual iFrames; (4) Technical controls for malicious JavaScript identification using Subresource Integrity; (5) Technical controls including client-side JavaScript malicious behavior in penetration testing requirements.
Complete preventive controls for marketing tags
The most complete and preventive 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; (3) Virtual frame Containment.
Data layer as secure standard for third-party JavaScript
The server direct mechanism is a good security standard for third-party JavaScript management, deployment and execution. A good corporate standard statement would be: 'The tag JavaScript can only access values in the host data layer. The tag JavaScript can never access a URL parameter.' The host page should create a data layer of DOM objects that performs validation of values, especially from user-exposed DOM objects like URL parameters and input fields.
Vendor agreements for third-party JavaScript security
Vendor agreements or requests for proposal should require evidence that vendors have implemented secure coding and general corporate server access security, with particular attention to monitoring and control of source code to prevent and detect malicious changes to JavaScript.
Tag manager technical security controls
Tag manager or aggregator sites offering graphical user interfaces for JavaScript configuration may implement technical controls such as restricting JavaScript to only access data layer values without accessing other DOM elements, and restricting tag types deployed on a host site such as disabling custom HTML tags and JavaScript code. The host company should verify tag manager security practices including access controls to tag configuration and two-factor authentication.
XSS risk in tag manager configuration
Letting marketing personnel decide where to get data through tag manager interfaces can result in XSS vulnerabilities if they retrieve data from URL parameters and store it into variables in scriptable page locations.
iframe sandbox attribute for third-party JavaScript
The iframe sandbox attribute can be used to secure iframes containing third-party vendor JavaScript by restricting capabilities while allowing specific permissions through attributes like "allow-same-origin" and "allow-scripts".
Scalability of data layer architecture
The data layer architecture is highly scalable for large ecommerce sites that can have hundreds of thousands of URL and parameter combinations with different sets being used in different marketing campaigns. Marketing logic can include 30 or 40 different vendor tags on a single page, with different event handler code determining which data layer elements are sent to the tag manager based on context. Changes to event handler code can be deployed in minutes without requiring interaction with third parties, and changing vendors only requires changing data dissemination rules at the tag manager server without modifying host code.
Types of third-party tags
Third-party vendor JavaScript tags can be divided into two types: (1) User interface tags that must execute on the client because they change the DOM by displaying dialogs or images or changing text; (2) Analytics tags that send information back to a marketing information database about user actions, browser metadata, location information, and page metadata.