You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: