【Web安全】第三方

什么是第三方？

一个网站是完全独立的，这是相当罕见的。HTTP网络年鉴显示，大多数网站（约95%）都包含一些第三方内容。

Almanac 将第三方内容定义为托管在共享和公共来源上的内容，该内容被各种网站广泛使用，不受单个网站所有者的影响。这些可能是图像或其他媒体，如视频、字体或脚本。图像和脚本所占的比其他所有内容加在一起还要多。第三方内容对开发网站来说并不重要，但也可以；几乎可以肯定的是，您将使用从公共共享服务器加载的东西，无论是网络字体、视频的嵌入式iframe、广告还是JavaScript库。例如，您可能正在使用Google fonts提供的网络字体，或者使用Google analytics测量分析；您可能添加了来自社交网络的“点赞”按钮或“登录方式”按钮；您可能正在嵌入地图或视频，或通过第三方服务处理购物；您可能正在通过第三方监控工具为自己的开发团队跟踪错误并进行日志记录。

出于隐私目的，考虑一个稍微不同且不那么宽泛的定义是有用的：第三方资源，尤其是第三方脚本，由共享和公共来源提供，并如图所示广泛使用，但也由网站所有者以外的人编写。在考虑如何保护用户隐私不受他人侵犯时，第三方作者身份是关键。这将使您考虑存在哪些风险，然后根据这些风险决定如何或是否使用第三方资源。如前所述，这些东西将帮助你理解上下文，从而理解你需要做出哪些权衡，以及它们的含义。

这并不是一般讨论“第三方资源”时的意思：第一方和第三方之间的区别实际上是关于使用某种东西的上下文。从另一个网站加载的脚本是第三方资源，加载脚本的HTTP请求可能包括cookie，但这些cookie并不是真正的“第三方cookie”；它们只是cookie，是“第三方”还是“第一方”取决于脚本是加载在您网站的页面上还是脚本所有者网站的页面。

我们为什么要使用第三方资源？

第三方是向您的网站添加功能的好方法。这可能是向用户公开的功能，也可能是错误跟踪等不可见的开发人员功能，但它们会减少您的开发负载，并且脚本本身由其他人维护：您所包含服务的开发团队。这一切之所以有效，是因为网络的可组合性：能够将部分放在一起，形成一个大于其总和的整体。

HTTP档案馆的网络年鉴给出了一个很好的描述：

第三方提供了一个永不停息的图像、视频、字体、工具、库、小工具、跟踪器、广告以及您可以想象嵌入我们网页的任何其他内容的集合。这使得即使是最非技术性的人也能够创建内容并将其发布到web上。如果没有第三方，网络可能会成为一个非常无聊、基于文本的学术媒介，而不是丰富、沉浸式、复杂的平台，而这个平台是我们今天许多人生活中不可或缺的一部分。

第三方资源可以做什么？

访问某些信息

当你在网站上使用第三方资源时，无论它是什么，一些信息都会传递给第三方。例如，如果您包含来自另一个网站的图像，则用户浏览器发出的HTTP请求将传递带有页面URL和用户IP地址的Referer标头。

跨站点跟踪

继续同一个例子——当图像从第三方网站加载时，它可以包括一个cookie，当用户下次请求该图像时，该cookie将被发送回第三方。这意味着第三方可以知道他们的服务正在你的网站上使用，它可以发回一个cookie，可能带有该用户的唯一ID。这意味着，下次用户访问您的网站或任何其他包含该第三方资源的网站时，将再次发送该唯一ID cookie。这允许第三方建立用户访问位置的日志：您的网站、使用相同第三方资源的其他网站，以及整个网络。

这是跨站点跟踪：允许第三方收集用户在许多网站上的活动日志，只要这些网站都使用来自同一第三方的资源。这可能是字体、图像或样式表——所有这些都是静态资源。它也可能是一个动态资源：一个脚本、一个社交媒体按钮、一个广告。包含的脚本可以收集更多的信息，因为它是动态的：它可以检查用户的浏览器和环境，并将数据传递回其创建者。任何脚本都可以在一定程度上做到这一点，不以脚本形式出现的动态资源也可以做到这一步，例如社交媒体嵌入、广告或共享按钮。如果你查看流行网站上cookie横幅的详细信息，你可以看到一个组织列表，这些组织可能会向你的用户添加跟踪cookie，以建立他们的活动图片，从而创建该用户的个人资料。可能有数百个。如果第三方免费提供服务，他们这样做在经济上可行的一种方式是收集这些数据，然后将其货币化。

目标隐私威胁模型是浏览器应保护用户免受隐私问题类型影响的有用指南。在撰写本文时，这是一份仍在讨论中的文件，但它对存在的各种隐私威胁进行了一些高级分类。第三方资源的风险主要是“不必要的跨站点识别”，即网站可以在多个站点上识别同一用户，以及“敏感信息披露”，即站点可以收集用户认为敏感的信息。

这是一个关键区别：即使第三方没有从中收集额外的敏感信息，不必要的跨站点识别也是糟糕的，因为它剥夺了用户对其身份的控制权。访问用户的推荐人(referrer)、IP地址和cookie本身就是一种不必要的披露。使用第三方资源附带了一个规划组件，说明如何以保护隐私的方式使用它们。其中一些工作由你作为网站开发人员负责，还有一些工作由浏览器作为用户代理完成；也就是说，代理代表用户工作，以尽可能避免敏感信息泄露和不必要的跨站点识别。下面，我们将更详细地了解浏览器级别和网站开发级别的缓解措施和方法。

服务器端第三方代码

我们之前对第三方的定义故意改变了HTTP年鉴的客户端方法（这适用于他们的报告！），将第三方作者包括在内，因为从隐私的角度来看，第三方是任何了解您的用户的人，而不是您。

这包括提供您在服务器和客户端上使用的服务的第三方。从隐私的角度来看，第三方库（例如NPM、Composer或NuGet中包含的内容）也很重要。您的依赖项是否将数据传递到边界之外？如果您将数据传递给日志记录服务或远程托管数据库，如果您包含的库也向其作者“打电话回家”，那么这些库可能会侵犯您用户的隐私，因此需要对其进行审计。基于服务器的第三方通常必须由您转交用户数据，这意味着它所暴露的数据更受您的控制。相比之下，基于客户端的第三方——包含在您的网站上并由用户浏览器获取的脚本或HTTP资源——可以直接从用户那里收集一些数据，而无需您进行收集过程。本模块的大部分内容将涉及如何识别您选择将用户包括在内并向其公开的客户端第三方，这正是因为您可以减少中介。但值得考虑的是，要保护服务器端代码的安全，这样您就可以了解来自它的出站通信，并可以记录或阻止任何意外的通信。关于如何做到这一点的详细信息不在我们的范围内（非常取决于您的服务器设置），但这是您的安全和隐私立场的另一部分。

为什么你需要小心对待第三方？

第三方脚本和功能非常重要，作为web开发人员，我们的目标应该是集成这些东西，而不是放弃它们！但也存在潜在的问题。第三方内容可能会造成性能问题，也可能会造成安全问题，因为您在信任边界内引入了外部服务。但第三方内容也会造成隐私问题！

当我们谈论网络上的第三方资源时，将安全问题视为（除其他外）第三方可以从您的公司窃取数据，并将其与隐私问题进行对比，隐私问题是（除其他事项外）您所包括的第三方向未经您（或他们）同意的情况下窃取或获取对您用户数据的访问。

安全问题的一个例子是“网络掠夺者”窃取信用卡信息——用户输入信用卡详细信息的页面上包含的第三方资源可能会窃取这些信用卡的详细信息，并将其发送给恶意第三方。那些创作这些吝啬剧本的人在寻找隐藏它们的地方方面非常有创意。一个摘要描述了如何在第三方内容中隐藏吝啬的脚本，如用于网站徽标、收藏夹和社交媒体网络的图像，jQuery、Modernizr和Google Tag Manager等流行库，实时聊天窗口和CSS文件等网站小部件。

隐私问题有点不同。这些第三方是您产品的一部分；为了保持用户对您的信任，您需要确信用户能够信任他们。如果您使用的第三方收集了有关您用户的数据，然后滥用这些数据，或使其难以删除或发现，或遭受数据泄露，或违反了您用户的期望，那么您的用户可能会认为这是他们对您服务的信任破裂，而不仅仅是对第三方的信任破裂。这是你的声誉和关系的问题。这就是为什么问自己很重要：你信任你在网站上使用的第三方吗？

第三方的一些例子是什么？

我们通常讨论的是“第三方”，但实际上有不同的种类，他们可以访问不同数量的用户数据。例如，将从不同服务器加载的＜img＞元素添加到HTML中，将为该服务器提供与添加＜iframe＞或＜script＞元素不同的用户信息。这些是示例，而不是全面的列表，但了解您的网站可以使用的不同类型的第三方项目之间的区别是很有用的。

请求跨站点资源

跨站点资源是指从其他站点加载的站点上的任何内容，而不是<iframe>或<script>。示例包括＜img＞、＜audio＞、＜video＞、CSS加载的web字体和WebGL纹理。这些都是通过HTTP请求加载的，如前所述，这些HTTP请求将包括其他网站先前设置的任何cookie、请求用户的IP地址和作为引用人的当前页面的URL。默认情况下，历史上所有第三方请求都包含此数据，尽管如“了解第三方浏览器保护”中所述，已努力减少或隔离各种浏览器传递给第三方的数据。

嵌入跨站点iframe

通过<iframe>嵌入页面的完整文档可以请求对浏览器API的额外访问，此外还有Cookie、IP地址和推荐人三项功能。具体哪些API可用于<iframe>d页面以及它们请求访问的方式是特定于浏览器的，并且目前正在进行更改：请参阅下面的“权限策略”，了解当前限制或监控嵌入文档中API访问的措施。

执行跨站点JavaScript

包含＜script＞元素将在页面的顶级上下文中加载并运行跨站点JavaScript。这意味着运行的脚本可以完全访问您自己的第一方脚本所做的任何事情。浏览器权限仍然管理这些数据，因此请求用户的位置（例如）仍然需要用户同意。但是，页面中存在的或作为JavaScript变量可用的任何信息都可以通过此类脚本读取，这不仅包括作为请求的一部分传递给第三方的cookie，还包括仅用于您的网站的cookie。同样，加载到页面上的第三方脚本可以发出与您自己的代码相同的HTTP请求，这意味着它可以向后端API发出fetch（）请求以获取数据。

在依赖项中包括第三方库

如前所述，您的服务器端代码也可能包括第三方依赖项，这些依赖项与您自己的代码无法区分；从GitHub存储库或编程语言库（npm、PyPI、composer等）中包含的代码可以读取与其他代码相同的所有数据。

了解您的第三方

因此，这需要了解您的第三方供应商名单，以及他们的隐私、数据收集和用户体验立场和政策。然后，这种理解就成为了一系列权衡的一部分：服务有多有用和重要，与他们对用户的要求有多侵扰、不方便或令人不安相平衡。第三方内容通过承担网站所有者的重任来提供价值，并使您能够专注于自己的核心能力；因此，做出这种权衡并牺牲一些用户舒适度和隐私以获得更好的用户体验是有价值的。重要的是不要将用户体验与开发人员体验混为一谈：“我们的开发团队更容易构建服务”对用户来说并不是一个引人注目的故事。

如何获得这种理解是审计的过程。

审计您的第三方

了解第三方的行为就是审计过程。你可以在技术上和非技术上都这样做，也可以为个人第三方和你的整个系列这样做。

运行非技术性审核

第一步是非技术性的：阅读供应商的隐私政策。如果您包含任何第三方资源，请检查隐私政策。它们将很长，充满法律文本，一些文件可能会使用早期模块中特别警告不要使用的一些方法，例如过于笼统的陈述，并且没有任何关于如何或何时删除收集的数据的指示。重要的是要认识到，从用户的角度来看，在您的网站上收集的所有数据，包括第三方收集的数据，都将受到这些隐私政策的管辖。即使你做的每件事都是正确的，当你对自己的目标是透明的，并且超出了用户对数据隐私和敏感性的期望时，用户也可能要求你对你选择的第三方所做的任何事情负责。如果他们的隐私政策中有什么你不想在自己的政策中说的，因为这会降低用户的信任，那么考虑是否有其他供应商。

这可以与进一步讨论的技术审计密切相关，因为它们相互通知。你应该知道你因商业原因（如广告网络或嵌入内容）而整合的第三方资源，因为这将是一种商业关系。这是开始非技术性审计的好地方。技术审计还可能确定第三方，特别是那些因技术而非业务原因（外部组件、分析、实用程序库）而被包括在内的第三方。该列表可以与以业务为重点的第三方列表一起使用。这里的目标是让你作为网站所有者，感觉自己了解你添加到网站的第三方在做什么，让你作为一家企业能够向你的法律顾问提供第三方的清单，以确保你履行了任何要求的义务。

运行技术审核

对于技术审计来说，将资源作为网站的一部分原位使用是很重要的；也就是说，不要在测试线束中加载依赖项并以这种方式进行检查。确保你看到了你的依赖关系是如何作为你实际网站的一部分，部署在公共互联网上，而不是在测试或开发模式中。以新用户的身份查看自己的网站是非常有指导意义的。在干净的新配置文件中打开浏览器，这样您就不会登录，也没有存储的协议，然后尝试访问您的网站。

注意：将网站视为新用户进行测试意味着查看该网站时不保存任何相关信息。在这种情况下，最好在每次测试网站时创建一个全新的配置文件，就好像您是新用户一样。不要创建一个新的配置文件并重复使用它；每次创建一个新的配置文件，然后将其丢弃。这在桌面浏览器上大多是一个快速的过程：请参阅Chrome、Edge和Firefox的文档。Chrome for Android和Safari不支持创建新的空配置文件，因此隐姓埋名/私人浏览模式就足够了，但总的来说，在隐名/私人浏览器模式和新创建的配置文件中测试网站是很重要的。
如果您提供用户帐户，请在自己的网站上注册一个新帐户。您的设计团队将从用户体验的角度精心安排这一新的用户获取过程，但从隐私的角度来处理它可能是例证。不要简单地点击条款和条件、cookie警告或隐私政策上的“接受”；为自己设定一项任务，即在不披露任何个人信息或拥有任何跟踪cookie的情况下使用自己的服务，看看你是否能做到这一点，以及做到这一步有多难。查看浏览器开发工具，了解哪些网站正在被访问，哪些数据被传递到这些网站，也会很有帮助。开发人员工具提供了一个单独的HTTP请求列表（通常在一个名为“网络”的部分），您可以从这里看到按类型分组的请求（HTML、CSS、图像、字体、JavaScript、由JavaScript发起的请求）。还可以添加一个新列来显示每个请求的域，这将显示正在联系的不同地点的数量，并且可能会有一个“第三方请求”复选框来只显示第三方。（使用内容安全策略报告执行持续审计也很有用，请参阅下文。）

Simon Hearne的“请求地图生成器”工具也可以对公开页面生成的所有子请求进行有用的概述。

这也是您可以将以业务为重点的第三方纳入非技术性审计的一部分（即：与您有财务关系以使用其资源的公司列表）。这里的目标是匹配您认为正在使用的第三方列表（来自财务和法律记录）和您实际使用的列表（通过查看您的网站发出的第三方HTTP请求）。您应该能够为每个业务第三方确定提出哪些技术出站请求。如果您无法在技术审计中确定针对业务关系确定的第三方的请求，那么很重要的一点是找出原因并指导您的测试：也许第三方资源仅在特定国家/地区、特定设备类型或登录用户中加载。这将扩大您要审核的站点区域列表，并确保您看到所有出站访问。（或者，它可能会识别出你正在付费而没有使用的第三方资源，这总是会让财务部门感到高兴。）

一旦您将请求列表缩小到您希望参与审计的第三方，单击单个请求将显示其所有详细信息，特别是传递给该请求的数据。代码发起的第三方请求然后继续发起许多其他第三方要求，这也是非常常见的。这些额外的第三方也会“导入”到您自己的隐私政策中。这项任务很费力，但很有价值，而且通常可以插入现有的分析中；您的前端开发团队应该已经出于性能原因对请求进行了审核（也许可以借助WebPageTest或Lighthouse等现有工具），并且将数据和隐私审核纳入该过程可以使其更容易。

 

A (dramatically simplified) request map for web.dev, showing third-party sites that request other third-party sites, and so on.

做

使用干净的新用户配置文件打开浏览器，这样您就不会登录，也没有存储的协议；然后打开浏览器开发工具“网络”面板，查看所有传出的请求。添加一个新列以显示每个请求的域，并选中“第三方请求”复选框以仅显示第三方（如果存在）。然后

• 访问您的网站。
• 如果您提供用户帐户，请注册一个新帐户。
• 尝试删除您创建的帐户。
• 在网站上执行一两个正常操作（具体是什么取决于你的网站做什么，但要选择大多数用户执行的常见操作）。
• 执行一两个您知道特别涉及第三方依赖关系的操作。这些可能包括将内容共享到社交媒体、开始结账流程或嵌入其他网站的内容。

在执行上述每项任务时，请按照说明查看“网络”面板，记录从非您的域请求的资源。这些是你的一些第三方。一个很好的方法是使用浏览器网络工具来捕获HAR文件中的网络请求日志。

HAR文件和捕获

HAR文件是一个页面发出的所有网络请求的标准化JSON格式。要获取特定页面的HAR文件，请在中：

Chrome

打开浏览器DevTools（菜单>更多工具>开发者工具），转到网络面板，加载（或刷新）页面，然后选择右上角无节流下拉菜单附近的向下箭头保存符号。

Chrome DevTools网络面板上突出显示了下载HAR符号。

Firefox

打开浏览器开发人员工具（菜单>更多工具>Web开发人员工具），转到“网络”面板，加载（或刷新）页面，然后选择节流下拉菜单右上角的齿轮符号。从菜单中，选择“全部另存为HAR**”。

Firefox开发人员工具网络面板上突出显示了Save All As Har选项。

Safari

打开浏览器开发工具（菜单>开发>显示Web检查器；如果您没有开发菜单，请从菜单栏中的菜单>Safari>首选项>高级>显示开发菜单启用它），转到网络面板，加载（或刷新）页面，然后选择右上角的导出（在保留日志的右侧；您可能需要放大窗口）。

突出显示HAR导出选项的Safari Web Inspector“网络”面板。
有关更多详细信息，您还可以记录传递给第三方的内容（在请求部分），尽管这些数据经常被混淆，无法进行有效的解释。

集成第三方时的最佳做法

您可以针对您的网站使用的第三方设置自己的策略：根据他们的做法，或他们的cookie同意弹出窗口有多烦人或侵入性，或您是否想使用网站上的社交媒体按钮，或电子邮件中的跟踪链接，或推文中的utm_campaign链接在谷歌分析中进行跟踪，来更改您使用的广告提供商。开发网站时需要考虑的一个方面是分析服务的隐私和安全状况。一些分析服务明确以保护隐私为代价。通常，也有使用第三方脚本的方法，该脚本本身就增加了隐私保护：您不是第一个希望改善用户隐私并保护他们免受第三方数据收集影响的团队，可能已经有了解决方案。最后，与过去相比，许多第三方提供商现在对数据收集问题更加敏感，并且通常可以添加一些功能或参数来启用更具用户保护性的模式。以下是一些例子。

添加社交媒体共享按钮时

考虑直接嵌入HTML按钮：网站https://sharingbuttons.io/有一些精心设计的例子。或者您可以添加纯HTML链接。这里的权衡是，你失去了“份额计数”统计数据，也失去了在Facebook分析中对客户进行分类的能力。这是使用第三方提供商和接收较少分析数据之间权衡的一个例子。

更一般地说，当您嵌入来自第三方的某种交互式小部件时，通常可以提供指向该第三方。这确实意味着你的网站没有内联体验，但它将与第三方共享数据的决定从你转移到了你的用户身上，用户可以根据自己的喜好选择交互或不交互。

例如，您可以添加Twitter和Facebook的链接，以便在mysite.example.com上共享您的服务，如下所示：

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

请注意，Facebook允许指定要共享的URL，Twitter允许指定URL和一些文本。

嵌入视频时

当你从视频托管网站嵌入视频时，在嵌入代码中寻找隐私保护选项。例如，对于YouTube，将嵌入URL中的YouTube.com替换为www.YouTube-nocookie.com，以避免跟踪在查看嵌入页面的用户身上放置的cookie。当从YouTube本身生成共享/嵌入链接时，您也可以选中“启用隐私增强模式”。这是使用第三方提供的更具用户保护性的模式的一个很好的例子。(https://support.google.com/youtube/answer/171780更详细地描述了这一点，以及YouTube的其他嵌入选项。）

其他视频网站在这方面的选择较少：例如，在撰写本文时，TikTok无法在不跟踪的情况下嵌入视频。可以自己主持视频（这是使用一种替代方案），但这可能需要做更多的工作，尤其是支持许多设备。

与前面讨论的交互式窗口小部件一样，通常可以将嵌入的视频替换为提供网站的链接。这是不太互动的，因为视频不会在线播放，但它留下了是否与用户一起观看的选择。这可以作为“门面模式”的一个例子，它是用需要用户操作才能触发的东西来动态替换交互式内容的名称。嵌入的TikTok视频可以用指向Tik Tok视频页面的普通链接来替换，但只要再做一点工作，就可以检索和显示视频的缩略图，并将其作为链接。即使所选的视频提供商不支持在不跟踪的情况下嵌入视频的简单方法，许多视频主机也支持oEmbed，这是一种API，当提供视频或嵌入内容的链接时，它将返回视频的程序细节，包括缩略图和标题。TikTok支持oEmbed（请参阅https://developers.tiktok.com/doc/embed-videos详细信息），这意味着你可以（手动或编程）打开TikTok视频的链接https://www.tiktok.com/@scout2015/video/6718335390845095173转换为关于该视频的JSON元数据https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173，并因此检索要显示的缩略图。例如，WordPress经常使用它来请求oEmbed的嵌入内容信息。您可以通过编程方式使用它来显示一个看起来交互式的“外观”，并在用户选择单击交互式视频时切换为嵌入或链接到该视频。

嵌入分析脚本时

分析旨在收集有关用户的信息，以便对其进行分析：这就是它的用途。分析系统本质上是收集和显示访问和用户数据的服务，这是在第三方服务器上完成的，如谷歌分析，以便于实现。还有自托管的分析系统，如https://matomo.org/，尽管这比使用第三方解决方案要多得多。不过，在您自己的基础设施上运行这样的系统确实有助于减少数据收集，因为它不会离开您自己的生态系统。另一方面，管理、删除数据并为其设置策略成为您的责任。当跨站点跟踪是秘密进行的，或者是使用完全不需要包含数据收集的服务的副作用时，就会引起人们对跨站点跟踪的担忧。分析软件公开设计用于收集数据，以便告知网站所有者有关其用户的信息。

从历史上看，有一种方法可以收集所有关于一切的数据，比如一个巨大的渔网，然后稍后对其进行分析，找出有趣的模式。这种心态在很大程度上造成了对本课程第1部分中讨论的数据收集的不安和不安。现在，许多网站首先确定要问哪些问题，然后收集特定且有限的数据来回答这些问题。

如果您的网站和其他网站使用某些第三方服务，并且您可以将其JavaScript包含到您的网站中，并为每个用户设置cookie，那么重要的是要考虑到他们可能正在进行不必要的跨网站识别；也就是说，跨站点跟踪用户。有些可能，有些可能不会，但这里的隐私保护立场是假设这样的第三方服务实际上正在进行跨站点跟踪，除非你有充分的理由思考或知道其他情况。这本身并不是避免此类服务的原因，但在评估使用这些服务的权衡时需要考虑这一点。

分析中的权衡过去只是选择是否使用它：收集所有数据并损害隐私以换取见解和规划，或者完全放弃见解。然而，现在情况已不再如此，在这两个极端之间往往有一个中间地带。请查看您的分析提供商的配置选项，以限制收集的数据并减少其存储量和持续时间。由于您有前面描述的技术审核的记录，因此可以重新运行该审核的相关部分，以确认更改这些配置确实减少了收集的数据量。如果你在现有网站上进行这种转换，那么这可以为你提供一些可以量化的衡量标准，可以为你的用户撰写。例如，谷歌分析有许多选择加入（因此默认关闭）的隐私功能，其中许多可能有助于遵守当地的数据保护法律。设置Google Analytics时需要考虑的一些选项包括将收集数据的保留期（管理>跟踪信息>数据保留）设置为低于26个月的默认值，以及启用一些更技术的解决方案，如部分IP匿名化（请参阅https://support.google.com/analytics/answer/9019185了解更多细节）。

以保护隐私的方式使用第三方

到目前为止，我们已经讨论了如何在应用程序的设计阶段保护您的用户不受第三方的影响，同时您正在计划该应用程序的操作。决定根本不使用特定的第三方是该计划的一部分，而审核您的使用也属于这一类：这是关于您的隐私立场的决定。然而，这些决定本质上不是很精细；选择使用特定的第三方或选择不使用不是一个微妙的决定。你更有可能想要介于两者之间的东西：需要或计划使用特定的第三方产品，但要减少任何侵犯隐私的倾向（无论是故意的还是意外的）。这是在“构建时”保护用户的任务：添加保护措施以减少您没有预料到的伤害。所有这些都是新的HTTP标头，您可以在提供页面时提供这些标头，这些标头将提示或命令用户代理采取某些隐私或安全立场。

推荐人政策Referrer-Policy

做

在交叉来源或noreferrer时设置严格来源的策略，以防止其他网站在链接到它们或被页面加载为子来源时接收到Referer标头：

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

或服务器端，例如在Express中：

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

如果需要，可以对特定元素或请求设置更宽松的策略。

为什么这样可以保护用户隐私

默认情况下，浏览器发出的每个HTTP请求都会传递一个Referer标头，该标头包含发起请求的页面的URL，无论是链接、嵌入图像还是脚本。这可能是一个隐私问题，因为URL可能包含私人信息，而第三方可以使用的URL会将私人信息传递给他们。Web.dev列出了一些包含私人数据的URL示例——知道用户从https://social.example.com/user/me@example.com告诉您该用户是谁，这是一个明确的泄漏。但是，即使是一个本身不公开私人信息的URL，也会暴露出这个特定的用户（如果他们登录了，你可能知道他）是从另一个网站来的，因此这表明这个用户访问了另一个站点。这本身就是暴露了你可能不应该知道的关于用户浏览历史的信息。

注：（拼写错误，是的：Referrer应该有一个双R。人们已经抱怨了四分之一个世纪了。）
通过提供Referrer Policy标头（拼写正确！），您可以更改该标头，以便传递部分或全部引用URL。MDN列出了完整的详细信息，但大多数浏览器在默认情况下跨来源时都采用了严格来源的假定值，这意味着引用URL现在仅作为来源传递给第三方(https://web.dev而不是https://web.dev/learn/privacy). 这是一个有用的隐私保护，您无需做任何事情。但您可以通过指定“推荐人政策”来进一步加强这一点：同源，以避免将任何推荐人信息传递给第三方（或“推荐人策略”：无推荐人，以避免传递给任何人，包括您自己的来源）。（这是隐私与效用平衡的一个很好的例子；新的默认设置比以前更能保护隐私，但它仍然为您选择的第三方（如您的分析提供商）提供高级别的信息。）

显式指定此标头也很有用，因为这样您就可以确切地知道策略是什么，而不是依赖于浏览器默认值。如果您无法设置标题，则可以使用<head>:<meta name=“referrer”content=“same origin”>中的元元素为整个HTML页面设置引用策略；如果关心特定的第三方，也可以在单个元素上设置referrpolicy属性，如＜script＞、＜a＞或＜iframe＞：＜script src=“https://thirdparty.example.com/data.js“referrpolicy=”no referrer“>

内容安全策略

内容安全策略标头（通常称为“CSP”）指示可以从何处加载外部资源。它主要用于安全目的，防止跨站点脚本攻击和脚本注入，但当与定期审计一起使用时，它也会限制您选择的第三方将数据传递到的位置。

这可能是一种不太好的用户体验；如果您的某个第三方脚本开始从不在您列表中的源加载依赖项，那么该请求将被阻止，脚本将失败，您的应用程序可能会随之失败（或者至少减少到其JavaScript失败的回退版本）。当CSP是为了安全而实现时，这是很有用的，这是它的正常目的：防止跨站点脚本问题（要做到这一点，请使用严格的CSP）。一旦您了解了页面使用的所有内联脚本，就可以列出它们的列表，为每个脚本计算一个哈希值或添加一个随机值（称为“nonce”），然后将哈希列表添加到内容安全策略中。这将阻止加载列表中没有的任何脚本。这需要融入到网站的生产过程中：页面中的脚本需要包括nonce，或者作为构建的一部分计算哈希。有关所有详细信息，请参阅关于严格csp的文章。

幸运的是，浏览器支持一个相关的头，即“仅内容安全策略报告”。如果提供了此标头，则不会阻止违反所提供策略的请求，但会将JSON报告发送到所提供的URL。这样的标头可能如下所示：Content Security policy report Only：script src 3p.example.com；报表urihttps://example.com/report/，如果浏览器从3p.example.com以外的任何位置加载脚本，则该请求将成功，但将向提供的报告uri发送报告。通常，这用于在实现策略之前对其进行实验，但这里的一个有用想法是将其用作进行“正在进行的审计”的一种方式。除了前面描述的定期审计外，您还可以打开CSP报告，查看是否出现任何意外域，这可能意味着您的第三方资源正在加载自己的第三方资源，您需要考虑和评估这些域。（当然，这也可能是一些跨站点脚本攻击已经越过您的安全边界的迹象，了解这一点也很重要！）

内容安全策略是一个复杂而棘手的API。这是众所周知的，目前正在进行构建“下一代”CSP的工作，它将实现相同的目标，但使用起来并不那么复杂。这还没有准备好，但如果你想看看它的发展方向（或者参与并帮助它的设计！）https://github.com/WICG/csp-next详细信息。

做

将此HTTP标头添加到提供的页面：仅限内容安全策略报告：默认src“self”；报表urihttps://a-url-you-control.当JSON被发布到该URL时，请将其存储。查看存储的数据，以获得您的网站在被他人访问时请求的第三方域的集合。更新“仅内容安全策略报告”标头以列出所需的域，以便查看该列表何时更改：

Content-Security-Policy-Report-Only: default-src 'self' 
https://expected1.example.com https://expected2.example.com ; 
report-uri https://a-url-you-control

为什么？

这是您技术审计的一部分，以持续的方式进行。您执行的初始技术审核将为您提供一份网站共享或传递用户数据的第三方列表。然后，此标题将导致页面请求报告当前正在联系的第三方向，您可以跟踪一段时间内的更改。这不仅会提醒您现有第三方所做的更改，还会标记未添加到技术审计中的新添加的第三方。更新标头以停止报告您期望的域很重要，但不时重复手动技术审核也很重要（因为内容安全策略方法不会标记传递的数据，只标记已发出请求。）

请注意，它不需要每次或每一页都添加到服务的页面中。调整接收标题的页面回复数量，这样您就可以收到数量不太多的具有代表性的报告样本。

权限策略

“权限策略”标头（以“功能策略”的名称引入）在概念上与“内容安全策略”相似，但它限制了对强大浏览器功能的访问。例如，可以限制设备硬件的使用，如加速度计、相机或USB设备，或者限制非硬件功能，如全屏或使用同步XMLHTTPRequest的权限。这些限制可以应用于顶级页面（以避免加载的脚本试图使用这些功能）或通过iframe加载的子框架页面。这种对API使用的限制并不是真正的浏览器指纹；这是关于禁止第三方做侵入性的事情（例如使用强大的API、弹出权限窗口等）。目标隐私威胁模型将其定义为“入侵”。

“权限策略”标头被指定为（功能、允许的原点）对的列表，因此：

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

此示例允许此页面（“self”）和origin example.com中的<iframe>s使用JavaScript中的navigator.geolocation API；它允许该页面和所有子帧使用全屏API，并禁止任何页面（包括该页面）使用相机读取视频信息。这里有更多的细节和潜在的例子列表。

由“权限策略”标头处理的功能列表很大，并且可能不断变化。目前，该列表保存在https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

提示：请注意，内容安全策略值用分号分隔，但权限策略值用逗号分隔，并且权限策略值周围有括号。详细信息在“权限策略”解释程序中指定。

做

默认情况下，支持权限策略的浏览器不允许在子框架中使用强大的功能，您必须采取行动启用它们！默认情况下，此方法是私有的。如果您发现站点上的子框架需要这些权限，您可以选择性地添加它们。但是，默认情况下没有应用于主页面的权限策略，因此主页加载的脚本（包括第三方脚本）不受限制，无法尝试使用这些功能。因此，默认情况下，将限制性的“权限策略”应用于所有页面，然后逐渐添加回页面所需的功能，这是非常有用的。

权限策略影响的强大功能示例包括请求用户的位置、访问传感器（包括加速计、陀螺仪和磁力计）、允许全屏显示以及请求访问用户的相机和麦克风。上面链接了（正在更改的）完整功能列表。

不幸的是，默认情况下阻止所有功能，然后选择性地重新允许它们，需要在标题中列出所有功能，这可能会让人觉得很不雅。尽管如此，这样的“权限策略”标头还是一个很好的起点。permissionspolicy.com有一个可方便点击的生成器来创建这样的头：使用它来创建一个禁用所有功能的头会导致以下结果：

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), 
cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), 
execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), 
midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), 
sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

了解web浏览器中内置的隐私功能

除了“构建时”和“设计时”保护外，还有在“运行时”发生的隐私保护：即在浏览器中实现的保护用户的隐私功能。作为网站开发人员，这些功能不是你可以直接控制或利用的——它们是产品功能——但它们是你应该注意的功能，因为你的网站可能会受到浏览器中这些产品决策的影响。这里举一个例子，说明这些浏览器保护可能会影响您的网站，如果您的客户端JavaScript在继续页面设置之前等待第三方依赖项加载，而该第三方依存项根本不会加载，那么您的页面设置可能永远不会完成，因此用户会看到一个加载了一半的页面。

其中包括Safari（及其底层WebKit引擎）中的智能跟踪保护，以及Firefox（及其引擎Gecko）中的增强跟踪保护。这些都使得第三方很难建立用户的详细档案。

浏览器在隐私功能方面的做法经常变化，保持最新信息很重要；以下保护列表在撰写本文时是正确的。浏览器还可以实现其他保护；这些清单并不详尽。请参阅最佳实践模块，了解如何跟上此处的更改，并确保使用即将推出的浏览器版本测试可能影响您的项目的更改。请记住，隐姓埋名/私人浏览模式有时会实现与浏览器默认设置不同的设置（例如，在这种模式下，第三方cookie可能会被默认阻止）。因此，如果大多数用户不使用私人浏览，匿名模式下的测试可能并不总是反映他们典型的浏览体验。还要记住，在各种情况下阻止cookie可能意味着其他存储解决方案，如window.localStorage，也会被阻止，而不仅仅是cookie。

Chrome

 

• 第三方cookie将来会被阻止。截至本文撰写之时，它们在默认情况下未被阻止（但用户可以启用）：https://support.google.com/chrome/answer/95647详细说明。
• 在privacysandbox.com/上介绍了Chrome的隐私功能，特别是与谷歌和第三方服务通信的功能。

Edge

 

• 默认情况下，第三方cookie不会被阻止（但用户可以启用）。
• Edge的“防止跟踪”功能会阻止未访问网站的跟踪器，并且默认情况下会阻止已知的有害跟踪器。

Firefox

 

• 默认情况下，第三方cookie不会被阻止（但用户可以启用）。
• Firefox的增强跟踪保护默认阻止跟踪cookie、指纹脚本、加密矿工脚本和已知跟踪器。(https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track提供了一些更多细节）。
• 第三方cookie是受站点限制的，因此每个站点基本上都有一个单独的cookie罐，不能在各个站点之间进行关联（Mozilla称之为“全面cookie保护”）。

要深入了解可能被阻止的内容并帮助调试问题，请单击地址栏中的屏蔽图标，或访问关于：Firefox中的保护（在桌面上）。

Safari

 

• 默认情况下会阻止第三方cookie。
• 作为其智能跟踪预防功能的一部分，Safari将传递到其他页面的推荐人减少为顶级网站，而不是特定页面：(https://something.example.com而不是https://something.example.com/this/specific/page).
• 浏览器localStorage数据在七天后被删除。
• (https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/总结了这些特征。）

要深入了解可能被阻止的内容并帮助调试问题，请在Safari的开发者菜单（桌面上）中启用“智能跟踪防止调试模式”。看见https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/了解更多详细信息。）

API建议书

为什么我们需要新的API？

虽然浏览器产品中新的隐私保护功能和策略有助于保护用户隐私，但它们也面临挑战。许多web技术可用于跨站点跟踪，尽管它们是为其他目的而设计和使用的。例如，我们每天使用的许多身份联合系统都依赖于第三方cookie。如今，出版商赖以获得收入的众多广告解决方案都建立在第三方cookie之上。许多欺诈检测解决方案都依赖于指纹识别。当第三方cookie和指纹识别消失时，这些用例会发生什么？

浏览器很难区分用例，也很容易出错，并可靠地将侵犯隐私的用途与其他用途区分开来。这就是为什么大多数主流浏览器已经或打算阻止第三方cookie和指纹识别，以保护用户隐私。

需要一种新的方法：随着第三方cookie的逐步淘汰和指纹识别的减少，开发人员需要专门构建的API，这些API符合用例（尚未消失），但以保护隐私的方式设计。目标是设计和构建不能用于跨站点跟踪的API。与上一节中描述的浏览器功能不同，这些技术渴望成为跨浏览器API。

API提案示例

下面的列表并不全面——它只是一些正在讨论的内容的一部分。

API提议替换基于第三方cookie的技术的示例：

• 身份用例：FedCM
• 广告使用案例：私人点击测量，可互操作的私人归因，归因报告，主题，FLEDGE，PARAKEET。

API提议替代建立在被动跟踪基础上的技术的示例：

• 欺诈检测用例：信任令牌。

其他API将来可以在没有第三方cookie的情况下构建的其他方案示例：

• 存储访问API

此外，另一种类型的API提议正在出现，试图采用特定于so-far浏览器的隐蔽跟踪缓解措施。一个例子是隐私预算。在这些不同的用例中，Chrome最初提出的API属于隐私沙盒的保护伞术语。

Global-Privacy-Control是一个旨在向网站传达用户希望任何收集的个人数据不与其他网站共享的标题。其意图与已停产的“请勿追踪”类似。

注：在21世纪初，消费者权益组织推动允许用户指定他们不想通过cookie或类似技术进行跟踪。所有主要的浏览器都将其实现为请求头Do Not Track，其值为1，用于向网站指示用户不希望被跟踪。这遭到了数据收集公司的大量抵制，而且没有要求遵守，而且基本上没有。在2010年代末，它在很大程度上被浏览器删除，负责的工作组也关闭了，称“没有迹象表明用户代理、第三方和整个生态系统有计划的支持”。

API提案的现状

这些API方案中的大多数尚未部署，或者仅部署在标志后面或有限的环境中进行实验。

这个公共孵化阶段很重要：浏览器供应商和开发人员收集讨论和经验，了解这些API是否有用，以及它们是否真的在做设计用途。开发人员、浏览器供应商和其他生态系统参与者使用此阶段对API的设计进行迭代。

目前，隐私小组在Github上的提案列表是最新提出的新API的最佳位置。

您需要使用这些API吗？

如果您的产品直接建立在第三方cookie或指纹识别等技术之上，您应该参与这些新的API，试用它们，并为讨论和API设计贡献您自己的经验。在所有其他情况下，在撰写本文时，您不一定需要了解这些新API的所有细节，但最好了解即将发生的事情。