Currently we expose a Sec-Fetch-Site header to servers, but hide this information from service workers. The Sec-Fetch-Site and origin headers are not populated until after the FetchEvent is handled by the service worker. This means the service worker can not reason about whether the incoming request is from a safe same-origin initiator or a potentially hostile cross-site initiator.
To address this we propose to add a Request.site getter that returns same-origin, same-site, or cross-site. The value would be based on the request's internal origin and origin tainting flag.
This was discussed at the recent SW virtual F2F: w3c/ServiceWorker#1604
Currently we expose a
Sec-Fetch-Site
header to servers, but hide this information from service workers. TheSec-Fetch-Site
andorigin
headers are not populated until after the FetchEvent is handled by the service worker. This means the service worker can not reason about whether the incoming request is from a safe same-origin initiator or a potentially hostile cross-site initiator.To address this we propose to add a
Request.site
getter that returnssame-origin
,same-site
, orcross-site
. The value would be based on the request's internal origin and origin tainting flag.This was discussed at the recent SW virtual F2F: w3c/ServiceWorker#1604