Third Party JavaScript Management Cheat Sheet / 第三方JavaScript管理速查表

Introduction / 介绍

Tags, aka marketing tags, analytics tags etc. are small bits of JavaScript on a web page. They can also be HTML image elements when JavaScript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

标签，也称为营销标签、分析标签等，是网页上的小块JavaScript代码。当JavaScript被禁用时，它们也可以是HTML图像元素。它们存在的原因是为了收集关于网络用户行为和浏览上下文的数据，以便网页所有者用于营销。

Third party vendor JavaScript tags (hereinafter, tags) can be divided into two types:

第三方供应商的JavaScript标签（以下简称为标签）可以分为两种类型：

• User interface tags.
  中文：用户界面标签。
• Analytic tags.
  中文：分析标签。

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

用户界面标签必须在客户端执行，因为它们会改变DOM；显示对话框或图像或更改文本等。

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc. The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

分析标签将信息发送回营销信息数据库；信息如用户刚刚执行了什么操作、浏览器元数据、位置信息、页面元数据等。分析标签的目的是将用户浏览器DOM中的数据提供给供应商进行某种形式的营销分析。这些数据可以是DOM中可用的任何数据。这些数据用于用户导航和点击流分析、识别用户以确定要显示的进一步内容等，以及各种营销分析功能。

The term host refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party JavaScript tag for marketing analysis of the user actions.

术语宿主指的是用户访问的原始网站，例如包含或检索并执行第三方JavaScript标签以进行用户行为营销分析的购物或新闻网站。

Major risks / 主要风险

The single greatest risk is a compromise of the third party JavaScript server, and the injection of malicious JavaScript into the original tag JavaScript. See RiskIQ's report of the 2018 Ticketmaster incident.

最大的风险是第三方JavaScript服务器的泄露，以及恶意JavaScript注入到原始标签JavaScript中。参见RiskIQ关于2018年Ticketmaster事件的报告。

The invocation of third-party JS code in a web application requires consideration for 3 risks in particular:

在Web应用程序中调用第三方JS代码需要特别考虑以下3个风险：

1. The loss of control over changes to the client application,
   中文：对客户端应用程序变更失去控制，
2. The execution of arbitrary code on client systems,
   中文：在客户端系统上执行任意代码，
3. The disclosure or leakage of sensitive information to 3rd parties.
   中文：敏感信息泄露给第三方。

Risk 1: Loss of control over changes to the client application / 风险1：对客户端应用程序变更失去控制

This risk arises from the fact that there is usually no guarantee that the code hosted at the third-party will remain the same as seen from the developers and testers: new features may be pushed in the third-party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

这种风险源于通常无法保证第三方托管代码与开发者和测试者所见的一致：第三方代码中可能随时推送新功能，从而可能破坏接口或数据流，并暴露应用程序对用户/客户的可用性。

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the third-party code (to prevent modifications while in-transit). See below for more details.

典型的防御措施包括但不限于：内部脚本镜像（防止第三方修改），子资源完整性（启用浏览器级别的拦截）和第三方代码的安全传输（防止传输过程中的修改）。更多详情请见下文。

Risk 2: Execution of arbitrary code on client systems / 风险2：在客户端系统上执行任意代码

For original research on vulnerable third-party integrations, see Randy Westergren's ad-network findings.

有关易受攻击的第三方集成的研究，请参阅 Randy Westergren 的广告网络发现。

This risk arises from the fact that third-party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this third-party code gets executed, thus granting the third-party the exact same privileges that were granted to the user (similar to XSS attacks).

这种风险源于第三方JavaScript代码在集成到网站/应用程序之前很少被调用方审查。当客户端到达托管网站/应用程序时，这段第三方代码会被执行，从而赋予第三方与用户相同的权限（类似于 XSS攻击）。

Any testing performed prior to entering production loses some of its validity, including AST testing (IAST, RAST, SAST, DAST, etc.).

在进入生产之前进行的任何测试都会失去一些有效性，包括 AST测试 (IAST, RAST, SAST, DAST, 等)。

While it is widely accepted that the probability of having rogue code intentionally injected by the third-party is low, there are still cases of malicious injections in third-party code after the organization's servers were compromised (ex: Yahoo, January 2014).

虽然普遍认为第三方有意注入恶意代码的概率很低，但在组织的服务器被入侵后，仍有第三方代码中恶意注入的案例（例如：Yahoo，2014年1月）。

This risk should therefore still be evaluated, in particular when the third-party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the third-party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

因此，这种风险仍然需要评估，特别是在第三方没有显示任何文档表明其执行的比调用组织本身更好的安全措施，或者至少是等效的措施时。另一个例子是托管第三方JavaScript代码的域名因维护该公司的破产或开发者放弃项目而到期。然后，恶意行为者可以重新注册该域名并发布恶意代码。

Typical defenses include, but are not restricted to:

典型的防御措施包括但不限于：

• In-house script mirroring (to prevent alterations by 3rd parties),
  中文：内部脚本镜像（防止第三方修改）
• Sub-resource integrity) （子资源完整性） (to enable browser-level interception),
• Secure transmission of the third-party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.
  中文：第三方代码的安全传输（防止传输过程中的修改）以及各种类型的沙箱。更多详情见下文。
• ...

Risk 3: Disclosure of sensitive information to 3rd parties / 风险3：向第三方泄露敏感信息

ClearSky's original Magecart investigation) （ClearSky的原始Magecart调查） documents payment-data theft through injected JavaScript.

When a third-party script is invoked in a website/application, the browser directly contacts the third-party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the third-party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the third-party, for example when visiting another organization's website that also invokes the third-party script.

当在网站/应用程序中调用第三方脚本时，浏览器会直接联系第三方服务器。默认情况下，请求包括所有常规HTTP头。除了浏览器的原始IP地址外，第三方还获取其他数据，例如非https请求中的引用者（例如，当访问另一个也调用第三方脚本的组织的网站时）以及第三方之前设置的任何cookie，例如访问另一个组织的网站时。

In many cases, this grants the third-party primary access to information on the organization's users / customers / clients. Additionally, if the third-party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

在许多情况下，这赋予了第三方对组织用户/客户/客户信息的初步访问权限。此外，如果第三方与其他实体共享脚本，它还会从所有其他实体收集二级数据，从而知道组织的访客是谁，以及他们与哪些其他组织互动。

A typical case is the current situation with major news/press sites that invoke third-party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the third-party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

一个典型的案例是当前主要新闻/媒体网站调用第三方代码（通常是广告引擎、统计和JavaScript API）的情况：任何访问这些网站的访客也会通知第三方。在许多情况下，第三方还知道每个特定用户具体点击了哪些新闻文章（通过HTTP引用者字段发生泄露），从而可以建立更深入的个人档案。

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

典型的防御措施包括但不限于：内部脚本镜像（防止将HTTP请求泄露给第三方）。用户可以通过在泄露的网站/应用程序（如新闻/媒体网站）上随机点击链接来减少他们的个人资料。更多详情见下文。

Third-party JavaScript Deployment Architectures / 第三方JavaScript部署架构

There are three basic deployment mechanisms for tags. These mechanisms can be combined with each other.

对于标签，有三种基本的部署机制。这些机制可以相互组合。

Vendor JavaScript on page / 页面上的供应商JavaScript

This is where the vendor provides the host with the JavaScript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like XSS attacks or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the JavaScript is commonly obfuscated.

这是供应商向主机提供JavaScript，并将它放置在主机页面上的情况。为了安全，主机公司必须审查代码，以查找任何漏洞，如XSS攻击或恶意行为，例如从DOM向恶意网站发送敏感数据。这通常很困难，因为JavaScript通常会被混淆。

<!-- Some host, e.g. foobar.com, HTML code here -->
<html>
<head></head>
    <body>
        ...
        <script type="text/javascript">/* 3rd party vendor javascript here */</script>
    </body>
</html>

JavaScript Request to Vendor / 向供应商请求JavaScript

This is where one or a few lines of code on the host page each request a JavaScript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor JavaScript. Each time the page is accessed the requests are made to the vendor site for the JavaScript, which then executes on the user browser.

这是主机页面上的一行或多行代码每次直接从供应商网站请求JavaScript文件或URL的情况。当创建主机页面时，开发者会包含供应商提供的代码行，这些代码行将请求供应商的JavaScript。每次访问页面时，都会向供应商网站发出请求以获取JavaScript，然后它在用户的浏览器上执行。

<!-- Some host, e.g. foobar.com, HTML code here -->`
<html>
    <head></head>
    <body>
        ...
        <!-- 3rd party vendor javascript -->
        <script src="https://analytics.vendor.com/v1.1/script.js"></script>
        <!-- /3rd party vendor javascript -->
    </body>
</html>

Indirect request to Vendor through Tag Manager / 通过标签管理器间接向供应商请求

This is where one or a few lines of code on the host page each request a JavaScript file or URL from a tag aggregator or tag manager site; not from the JavaScript vendor site. The tag aggregator or tag manager site returns whatever third party JavaScript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other JavaScript files from multiple vendors.

这是主机页面上的一行或多行代码每次从标签聚合器或标签管理器网站请求JavaScript文件或URL的情况；而不是从JavaScript供应商网站请求。标签聚合器或标签管理器网站返回主机公司配置为返回的任何第三方JavaScript文件。对标签管理器网站的每个文件或URL请求都可能返回来自多个供应商的大量其他JavaScript文件。

The actual content that is returned from the aggregator or manager (i.e. the specific JavaScript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business.

从聚合器或管理器返回的实际内容（即特定的JavaScript文件以及它们的确切功能）可以通过在标签管理器网站上托管的开发图形用户界面动态更改，非技术用户可以在此处工作，例如业务的市场部分。

The changes can be either:

更改可以是以下之一：

1. Get a different JavaScript file from the third-party vendor for the same request.
   中文：从第三方供应商获取与同一请求不同的JavaScript文件。
2. Change what DOM object data is read, and when, to send to the vendor.
   中文：更改要读取的DOM对象数据及其读取时间，以便发送给供应商。

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a container JavaScript file to the browser which is basically a set of JavaScript functions that are used by the code generated by the user interface to implement the required functionality.

标签管理器开发者用户界面将生成代码，以实现营销功能所需的功能，基本上确定从浏览器DOM获取哪些数据以及何时获取。标签管理器始终向浏览器返回一个容器JavaScript文件，这基本上是一组JavaScript函数，由用户界面生成的代码使用以实现所需的功能。

Similar to java frameworks that provide functions and global data to the developer, the container JavaScript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know JavaScript.

类似于为开发者提供函数和全局数据的Java框架，容器JavaScript在浏览器上执行，并允许业务用户使用标签管理器开发者用户界面指定高级功能，而无需了解JavaScript。

<!-- Some host, e.g. foobar.com, HTML code here -->
 <html>
   <head></head>
     <body>
       ...
       <!-- Tag Manager -->
       <script>(function(w, d, s, l, i){
         w[l] = w[l] || [];
         w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
         var f = d.getElementsByTagName(s)[0],
         j = d.createElement(s),
         dl = l != 'dataLayer' ? '&l=' + l : '';
         j.async=true;
         j.src='https://tagmanager.com/tm.js?id=' + i + dl;
         f.parentNode.insertBefore(j, f);
       })(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>
       <!-- /Tag Manager -->
   </body>
</html>`

Security Problems with requesting Tags / 请求标签时的安全问题

The previously described mechanisms are difficult to make 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. The JavaScript is generally obfuscated so even seeing it is usually not useful. 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. One way to manage this risk is with the Subresource Integrity standard described below.

之前描述的机制难以使其安全，因为只有当你代理请求或获取对GUI的访问权限并查看配置时，你才能看到代码。JavaScript通常被混淆，所以即使看到它通常也没有什么用处。它还可以即时部署，因为浏览器从聚合器执行每个新页面请求时，都会执行对聚合器的请求，从而从第三方供应商获取JavaScript。因此，一旦供应商或聚合器上的任何JavaScript文件被更改或修改，任何浏览器对它们的下一次调用都将获取更改后的JavaScript。管理这种风险的一种方法如下所述的子资源完整性标准。

Server Direct Data Layer / 服务器直接数据层

The tag manager developer user interface can be used to create JavaScript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute JavaScript.

标签管理器开发者用户界面可用于创建JavaScript，可以从浏览器DOM的任何位置获取数据并将其存储在页面上的任何位置。这可能导致漏洞，因为该界面可以用于生成代码从DOM（例如URL参数）获取未经验证的数据并将其存储在页面上的某个位置，该位置将执行JavaScript。

Use a host-defined data layer to limit the data intended for collection. This agreement does not restrict the privileges of JavaScript executing in the page.

使用主机定义的数据层来限制要收集的数据。本协议不限制在页面中执行的JavaScript的权限。

The data layer is either:

数据层可以是：

1. a DIV object with attribute values that have the marketing or user behavior data that the third-party wants
   中文：一个具有营销或第三方希望的用户行为数据的属性值的DIV对象
2. a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.
   中文：一组具有相同数据的JSON对象。每个变量或属性包含某个DOM元素的值或用户动作的描述。数据层是所有供应商为该页面所需的所有值的完整集合。数据层由主机开发者创建。

When specific events happen that the business has defined, a JavaScript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

当发生业务定义的特定事件时，该事件的JavaScript处理程序将数据层的值直接发送到标签管理器服务器。然后，标签管理器服务器将数据发送给应该获取它的第三方或多方。事件处理程序代码由主机开发者使用标签管理器开发者用户界面创建。事件处理程序代码在每次页面加载时从标签管理器服务器加载。

A data layer is not a sandbox. Web tag-manager containers can execute custom JavaScript and HTML tags in the browser, so remotely managed event handlers remain part of the page's code trust boundary. Restrict tag-manager publishing access and review changes as application code.

数据层不是一个沙盒。Web标签管理器容器可以在浏览器中执行自定义JavaScript和HTML标签，因此远程管理的处理程序仍然是页面代码信任边界的一部分。限制标签管理器发布访问权限并审查更改作为应用程序代码。

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

Security Defense Considerations

Server Direct Data Layer / 服务器直接数据层

A server-side collector can filter the data sent to vendors and move eligible tags out of the browser. It does not isolate any scripts that still run in the page.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag JavaScript can only access values in the host data layer. The tag JavaScript can never access a URL parameter.

You the host page developer have to agree with the third-party vendors or the tag manager what attribute in the data layer will have what value so they can create the JavaScript to read that value.

您作为主机页面的开发者，必须与第三方供应商或标签管理器协商，确定数据层中哪些属性将具有哪些值，以便他们可以创建读取该值的JavaScript代码。

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

由于数据层架构中它们的函数（或其中之一）是改变客户端的用户界面，而不是发送关于用户操作的数据，因此无法使用数据层架构来使用户界面标签安全。

For analytics that do not need browser execution, send a fixed event schema through a collector you control and run vendor integrations server-side. Server-side tagging complements rather than replaces client-side collection. Audit the scripts actually loaded before claiming that only first-party code executes.

对于不需要浏览器执行的分析，请通过您控制的收集器发送固定的事件模式，并在服务器端运行供应商集成。服务器端标记补充而不是取代客户端收集。在声称只有第一方代码执行之前，请审计实际加载的脚本。

This is also a very scalable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page.

这也是一个非常可扩展的解决方案。大型电子商务网站可以轻松地拥有数十万个URL和参数组合，不同的URL和参数组合包含在不同的营销分析活动中。单个页面上可能有30个或40个不同的供应商标签。

For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.

例如，关于指定城市的页面上的用户操作应发送数据层元素1、2和3。关于其他城市的页面上的用户操作应仅发送数据层元素2和3。由于每个页面上发送数据层数据的处理程序代码由使用标签管理器开发者界面的主机开发者或营销技术人员控制，因此何时以及发送哪些数据层元素到标签管理器服务器上的业务逻辑可以在几分钟内更改和部署。无需与第三方交互；他们继续获得他们期望的数据，但现在这些数据来自主机营销技术人员选择的不同上下文。

Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code. The data also goes directly only to the tag manager so the execution is fast. The event handler JavaScript does not have to connect to multiple third party sites.

更改第三方供应商仅意味着更改标签管理器服务器上的数据分发规则，主机代码无需更改。数据也直接只发送到标签管理器，因此执行速度快。事件处理程序JavaScript无需连接到多个第三方网站。

Indirect Requests / 间接请求

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the JavaScript, they may also implement:

对于提供GUI以配置JavaScript的标签管理器/聚合器网站的间接请求，它们也可能实现：

• Technical controls such as only allowing the JavaScript to access the data layer values, no other DOM element
  中文：仅允许JavaScript访问数据层值的技术控制，不允许其他DOM元素
• Restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and JavaScript code
  中文：限制托管网站上部署的标签类型，例如禁用自定义HTML标签和JavaScript代码

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

托管公司还应验证标签管理网站的网络安全实践，例如验证托管公司对标签配置的访问控制。它还可以是双因素认证

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

让市场营销人员决定他们想要的数据来源可能会导致XSS攻击，因为他们可能从URL参数中获取数据并将其放入页面上的可脚本位置变量中

Sandboxing Content / 沙箱内容

Both of these tools be used by sites to sandbox/clean DOM data.

这两个工具都可以由网站用于沙箱/清理DOM数据

• DOMPurify is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
• MentalJS is a JavaScript parser and sandbox. It allow-lists JavaScript code by adding a "$" suffix to variables and accessors.

Subresource Integrity / 子资源完整性

Subresource Integrity) （子资源完整性） will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor JavaScript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
   integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
   crossorigin="anonymous">
</script>

It is important to know that in order for SRI to work, the vendor host needs CORS enabled. Also it is good idea to monitor vendor JavaScript for changes in regular way. Because sometimes you can get secure but not working third-party code when the vendor decides to update it.

重要的是要知道，为了使SRI工作，供应商主机需要启用CORS。此外，定期监控供应商JavaScript的更改也是一个好主意。因为有时当供应商决定更新它时，你可能会得到安全但不工作的第三方代码。

Keeping JavaScript libraries updated / 保持JavaScript库更新

OWASP Top 10:2025 A03 Software Supply Chain Failures) （OWASP Top 10:2025 A03 软件供应链故障） describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous versions can have known vulnerabilities which can lead to the site typically being vulnerable to Cross Site Scripting. There are several tools out there that can help identify such libraries. One such tool is the free open source tool RetireJS

Sandboxing with iframe / 使用iframe进行沙箱隔离

You can also put vendor JavaScript into an iframe from different domain (e.g. static data host). It will work as a "jail" and vendor JavaScript will not have direct access to the host page DOM and cookies.

您还可以将供应商JavaScript放入来自不同域的iframe中（例如，静态数据主机）。它将作为一个“监狱”，供应商JavaScript将无法直接访问宿主页面的DOM和cookies。

The host main page and sandbox iframe can communicate between each other via the postMessage mechanism.

宿主页和沙箱iframe可以通过postMessage机制相互通信。

Also, iframes can be secured with the iframe sandbox attribute.

此外，iframe可以通过iframe的sandbox属性进行安全设置。

For high risk applications, consider the use of Content Security Policy (CSP) in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

对于高风险应用，除了iframe沙箱隔离外，还应考虑使用[内容安全策略（CSP）](https://www.w3.org/TR/CSP2/）。CSP使得防止XSS攻击更为坚固。

<!-- Some host, e.g. somehost.com, HTML code here -->
 <html>
   <head></head>
     <body>
       ...
       <!-- Include iframe with 3rd party vendor javascript -->
       <iframe
       src="https://somehost-static.net/analytics.html"
       sandbox="allow-same-origin allow-scripts">
       </iframe>
   </body>
 </html>

<!-- somehost-static.net/analytics.html -->
 <html>
   <head></head>
     <body>
       ...
       <script>
       window.addEventListener("message", receiveMessage, false);
       function receiveMessage(event) {
         if (event.origin !== "https://somehost.com:443") {
           return;
         } else {
         // Make some DOM here and initialize other
        //data required for 3rd party code
         }
       }
       </script>
       <!-- 3rd party vendor javascript -->
       <script src="https://analytics.vendor.com/v1.1/script.js"></script>
       <!-- /3rd party vendor javascript -->
   </body>
 </html>

Virtual iframe Containment / 虚拟iframe隔离

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment JavaScript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

该技术创建的iframe与主页面异步运行。它还提供自己的隔离JavaScript，根据营销标签需求自动实现受保护iframe的动态实施。

Vendor Agreements / 供应商协议

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that JavaScript.

你可以要求与第三方签订协议或提案，要求他们提供已实施安全编码和一般企业服务器访问安全性的证据。但特别是你需要确定他们源代码的监控和控制，以防止和检测对JavaScript的恶意更改。

MarTechSec

Marketing Technology Security

营销技术安全

This refers to all aspects of reducing the risk from marketing JavaScript. Controls include

这指的是降低营销JavaScript风险的各个方面。控制措施包括

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.
   中文：风险降低的合同控制；与任何MarTech公司的合同应包括展示代码安全和代码完整性监控证据的要求。
2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious JavaScript
   中文：风险转移的合同控制：与任何MarTech公司的合同可以包括对提供恶意JavaScript的处罚。
3. Technical controls for malicious JavaScript execution prevention; Virtual Iframes,
   中文：防止恶意JavaScript执行的技術控制；虚拟Iframes，
4. Technical controls for malicious JavaScript identification; Subresource Integrity.
   中文：恶意 JavaScript 识别的技术控制；子资源完整性。
5. Technical controls including client side JavaScript malicious behavior in penetration testing requirements.
   中文：包括渗透测试要求中客户端JavaScript恶意行为的技術控制。

MarSecOps

Marketing Security Operations

营销安全运营

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

这指的是维护一些技术控制的操作要求。这可能涉及营销团队、MarTech提供商和运行或运营团队之间的可能合作和信息交换，以更新页面控制（SRI哈希更改、带有SRI的页面更改）、虚拟iFrames中的策略、标签管理器配置、数据层更改等。

The most complete and preventive controls for any site containing non-trivial marketing tags are -

包含非平凡营销标签的任何网站最完整和预防性的控制措施是 -

1. A controlled collector and server-side vendor integrations to reduce third-party browser code; a data layer alone does not enforce code isolation.
   中文：控制收集器和服务器端供应商集成以减少第三方浏览器代码；仅数据层本身并不能强制执行代码隔离。

2. Subresource Integrity) （子资源完整性）.

3. Virtual frame Containment.
   中文：虚拟帧隔离。

The MarSecOps requirements to implement technical controls at the speed of change that marketing wants or without a significant number of dedicated resources, can make data layer and Subresource Integrity controls impractical.

MarSecOps要求以营销所期望的速度或在不显著增加专用资源的情况下实施技术控制，可能会使数据层和子资源完整性控制变得不切实际。

References / 参考

• W3C: Subresource Integrity) （W3C：子资源完整性）
• W3C: Content Security Policy Level 3) （W3C：内容安全策略第3级）
• MDN: Window.postMessage()