2

我无法访问我的服务器以启用 COOP 和 COEP 标头，但我可以使用以下脚本通过服务工作者添加它们https://github.com/gzuidhof/coi-serviceworker，该脚本注册了一个服务工作者标题处于活动状态。

我需要 COOP 和 COEP 才能启用SharedArrayBuffer，这是为了避免受到 Spectre 和 Meltdown 的影响而受到限制。

我的问题是通过服务工作者添加 https 标头是否会带来安全风险，因为标头未在服务器级别设置。

在本文的底部，它认为这不是风险， https://dev.to/stefnotch/enabling-coop-coep-without-touching-the-server-2d3n

但我希望能得到一个解释，以更好地了解服务工作者方法是否同样安全，或者留下开放的漏洞。

谢谢！

4

1 回答 1

1

从安全角度来看，通过服务工作者添加这些标头是等效的，它将启用等效的功能。不过，有几点需要记住：

  • 在用户第一次导航到站点时或在轮班重新加载之后，服务人员无法控制客户端页面。通过实际的 Web 服务器设置这些标头是保证它们适用于这些场景的唯一方法。一般来说，如果您的主 Web 应用程序中有任何依赖于 Service Worker 存在的功能，您应该小心优雅地降级。

  • 让服务工作者控制页面会产生轻微的开销。如果您通过直接访问本地缓存而不是网络来响应请求，那通常会超过开销。由于您似乎不打算在 Service Worker 中进行任何缓存，因此您应该对导航预加载进行功能检测并在支持时启用它。这将减轻潜在的性能影响。

  • 仅需要在可以创建客户端的响应上设置标头，例如对文档或工作人员的响应。我建议在调用event.respondWith(). 这将帮助您的处理程序与任何其他可能也已注册fetch的处理程序很好地配合使用，例如使用缓存策略响应子资源请求。像下面这样的东西应该可以工作：fetch

self.addEventListener("fetch", (event) => {
  if (!["document", "iframe", "worker"].includes(event.request.destination)) {
    return;
  }

  event.respondWith(/* your logic here */);
});
于 2021-10-19T16:34:58.813 回答