Web技术

饼干最好是新鲜的，那么有什么最新的食谱可以确保你仍然可以在没有任何变质饼干的情况下享受诡异的季节呢？

我们正在逐步淘汰网络平台上的第三方cookie。这是解决跨站点跟踪问题的一个重要里程碑，但这是相当漫长的旅程的一部分。让我们来看看我们已经走了多远，未来会有什么美食…

从表面上看，cookie提供了一个在浏览器和服务器之间发送的简单键值存储。这可以在网站上提供有用的功能，例如保存首选项：theme=bats或存储已登录用户的会话ID。

介绍

Passkeys是一种更安全、更容易替代密码的方法。使用密钥，用户可以使用生物识别传感器（如指纹或面部识别）、PIN或模式登录应用程序和网站，从而无需记住和管理密码。

开发人员和用户都讨厌密码：它们给用户带来了糟糕的用户体验，增加了转换摩擦，并给用户和开发人员带来了安全责任。安卓和Chrome中的谷歌密码管理器通过自动填充减少了摩擦；对于寻求在转换和安全性方面进一步改进的开发人员来说，密钥和身份联合是该行业的现代方法。

密钥可以在一个步骤中满足多因素身份验证要求，取代密码和OTP（例如6位短信代码），以提供强大的保护，防止网络钓鱼攻击，并避免短信或基于应用程序的一次性密码带来的用户体验痛苦。由于密钥是标准化的，因此单个实现可以实现跨所有用户设备、跨不同浏览器和操作系统的无密码体验。

密钥更容易：

浏览器的同源策略阻止从不同的源读取资源。这种机制阻止恶意网站读取其他网站的数据，但也阻止合法使用。

现代web应用程序通常希望从不同的来源获取资源，例如，从不同的域检索JSON数据，或将另一个网站的图像加载到＜canvas＞元素中。这些可以是公共资源，任何人都可以阅读，但同源政策阻止了它们的使用。开发人员历来使用诸如JSONP之类的变通方法。

跨来源资源共享（CORS）以标准化的方式解决了这个问题。启用CORS可以让服务器告诉浏览器它可以使用一个额外的原点。

你为什么要关心隔离你的网络资源？

许多web应用程序容易受到跨来源攻击，如跨站点请求伪造（CSRF）、跨站点脚本包含（XSSI）、定时攻击、跨来源信息泄露或推测执行侧通道（Spectre）攻击。

Fetch Metadata请求头允许您部署一种强大的深度防御机制——资源隔离策略——以保护您的应用程序免受这些常见的跨源攻击。

由给定的web应用程序公开的资源通常只由应用程序本身加载，而不由其他网站加载。在这种情况下，部署基于Fetch Metadata请求头的资源隔离策略几乎不需要付出什么努力，同时可以保护应用程序免受跨站点攻击。

浏览器兼容性

所有现代浏览器引擎都支持获取元数据请求标头。

浏览器支持

大多数时候，http://localhost出于开发目的，其行为类似HTTPS。然而，也有一些特殊情况，例如自定义主机名或跨浏览器使用安全cookie，在这些情况下，您需要明确设置您的开发网站，使其表现得像HTTPS，以准确地表示您的网站在生产中的工作方式。（如果您的生产网站不使用HTTPS，请优先切换到HTTPS）。

本页介绍如何使用HTTPS在本地运行您的网站。

注意：在本文中，关于localhost的语句也适用于127.0.0.1和[：：1]，因为它们都描述了本地计算机地址（也称为环回地址）。为了简单起见，这些说明没有指定端口号。所以当你看到http://localhost，读作http://localhost:｛PORT｝或http://127.0.0.1:｛端口｝。

有关简要说明，请参阅mkcert快速参考**

使用COOP和COEP来建立一个跨原点的隔离环境，并以更好的精度启用强大的功能，如SharedArray Buffer、performance.measureUserAgentSpecificMemory（）和高分辨率计时器。

注意：Chrome桌面上的SharedArrayBuffer需要从Chrome 92开始进行跨源隔离。在Android Chrome 88和Desktop Chrome 92中的SharedArray Buffer更新中了解更多信息。

了解为什么需要跨源隔离才能使用强大的功能，如SharedArray Buffer、performance.measureUserAgentSpecificMemory（）和精度更高的高分辨率计时器。

介绍

在使用COOP和COEP使您的网站“跨源隔离”的过程中，我们解释了如何使用COOP和COEP采用“跨源隔离”状态。这是一篇配套文章，解释了为什么需要跨源隔离才能在浏览器上启用强大的功能。

关键词：这篇文章使用了许多听起来相似的术语。为了使事情更清楚，让我们定义它们：

“同一网站”【"Same-site" 】和“同源”【"same-origin"】是经常被引用但经常被误解的术语。例如，它们用于页面转换、fetch（）请求、cookie、打开弹出窗口、嵌入资源和iframe的上下文。本页解释了它们是什么以及它们之间的区别。

• 警告：浏览器正在限制第三方cookie的使用。如果您过去在cookie上设置过SameSite=None，则必须采取其他操作。了解如何准备第三方cookie限制。

注意：此页面是SameSite cookie属性更改系列的一部分，其中包括：

• 了解Cookie
• SameSite cookie解释
• 有计划的相同站点

Chrome、Firefox、Edge和其他公司正在根据IETF的提案“Incrementally Better Cookies”更改其默认行为，以便：

• 没有SameSite属性的Cookie被视为SameSite=Lax，这意味着默认行为是将Cookie仅限于第一方上下文。
• 跨站点使用的Cookie必须指定SameSite=None；确保能够包含在第三方环境中。

如果您还没有这样做，您应该更新第三方cookie的属性，这样它们将来就不会被阻止。

浏览器支持

警告：浏览器正在限制第三方cookie的使用。如果您过去在cookie上设置了SameSite=None，则需要采取其他操作。了解如何准备第三方cookie限制。

注意：此页面是SameSite cookie属性更改系列的一部分，其中包括以下内容：

• 了解Cookie
• SameSite饼干配方
• 有计划的相同站点

每个cookie都包含一个键值对以及控制cookie何时何地使用的许多属性。

SameSite属性（在RFC6265bis中定义）的引入允许您声明您的cookie是限于第一方还是同一站点上下文。准确理解“site”在这里的含义是很有帮助的。该站点是域后缀和其前面的域部分的组合。例如，www.web.dev域是web.dev站点的一部分。

关键术语：如果用户在www.web.dev上，并从static.web.dev请求图像，则是同一个网站请求。