fetch
fetch copied to clipboard
whatwg
Extend Cross-Origin-Resource-Policy to take origin values
In #687 there was a strong interest, notably by @arturjanc, to make Cross-Origin-Resource-Policy accept literal origins.
Things to decide:
- Multiple values or not.
- Byte-for-byte matching after any splitting if we do multiple values (yes please).
This also means we can no longer fail open. E.g., the tests in https://github.com/web-platform-tests/wpt/pull/11427 would have to be flipped so they expect rejection instead since we do not know that the unrecognized values are not origins.
cc @johnwilander @youennf
What is the main problem that this issue attempts to solve? Is this mostly about the problem described by @arturjanc in https://github.com/whatwg/fetch/issues/687#issuecomment-385048931:
The problem with not allowing granular control in From-Origin is that it will be impossible for developers whose resources are loaded cross-site to use the header, even if they fully control the requesting domain.
cc @mikewest
Also (for helping with prioritization), do you think supporting cross-site Cross-Origin-Resource-Policy (e.g. by making Cross-Origin-Resource-Policy accept literal origins) is more or less important than working on finalizing and implementing Sec-Fetch-Site?
cc @csreis
From an individual website developer's view, this can effectively address the hotlinking issues. The region where my website's users are located demands expensive server bandwidth, and service providers like Vercel and Cloudflare, which are more cost-effective or even free, cannot offer stable services in that area. When some larger websites unauthorizedly use certain images/videos, the impact on my website is no less than DDoS attacks (pricewise). Nearly every local CDN provider offers anti-hotlinking services based on Referer. However, Referer is no longer accurate enough for long; referrerpolicy can easily bypass it, simply blocking empty referers also blocks many legitimate accesses. The same-site feature of CORP to a certain extent can address this issue, but often the CDN and the user visiting domain are not the same site, which is not flexible enough. If it were possible to specify the scope of the resources, the adoption rate of CORP would likely be much higher.
