使用 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 */);
});
我无法访问我的服务器以启用 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 yourfetch
handler play nicely with any otherfetch
handlers that might also be registered 以及哪个,例如使用缓存策略响应子资源请求。像下面这样的东西应该可以工作:
self.addEventListener("fetch", (event) => {
if (!["document", "iframe", "worker"].includes(event.request.destination)) {
return;
}
event.respondWith(/* your logic here */);
});