使用 service worker 启用 COOP/COEP headers :安全问题?

Using service worker to enable COOP/COEP headers : security concerns?

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

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

我的问题是通过 service worker 添加 https headers 是否会带来安全风险,因为 headers 没有在服务器级别设置。

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

但我希望得到解释,以便更好地理解 service-worker 方法是否同样安全,或者是否留下了开放的漏洞。

谢谢!

从安全角度来看,通过 Service Worker 添加那些 headers 是等效的,并且它将启用等效的功能。不过,有几点需要牢记:

  • 服务工作者无法在用户第一次导航到站点或跟随 shift-reload 期间控制客户端页面。通过实际的 Web 服务器设置这些 headers 是保证它们适用于这些场景的唯一方法。一般来说,如果您的主要 Web 应用程序中有任何功能依赖于 Service Worker 的存在,您应该小心优雅地降级。

  • 让 Service Worker 控制页面会产生一些开销。如果您通过直接进入本地缓存而不是网络来响应请求,那通常会超过开销。由于您似乎不打算在 Service Worker 中进行任何缓存,因此您应该 feature-detect for navigation preloads 并在支持时启用它。这将减轻潜在的性能影响。

  • headers只需要在可以创建客户端的响应上设置,例如文档或工人的响应。我建议检查您的服务人员是否 request's destination is for one of those things before calling event.respondWith(). This will help your fetch handler play nicely with any other fetch handlers that might also be registered 以及哪个,例如使用缓存策略响应子资源请求。像下面这样的东西应该可以工作:

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

  event.respondWith(/* your logic here */);
});