FAQ: How to use this for hotlinking protection

[briansmith]

(Note the issue isn't what the feature is intended to do, but what it is capable of doing.)

A quick reading of the documentation for this suggests that it could be used to prevent hotlinking of images, video, etc. by rejecting requests for such content that don't have site=same-site or site=same-origin. Does this work? In particular, would this have the the effect as Cross-Origin-Resource-Policy: same-site or Cross-Origin-Resource-Policy: same-origin, but with the added benefit that the server can avoid sending a the content in a response that would otherwise be ignored under the analogous Cross-Origin-Resource-Policy?

If so, then a follow-up FAQ question: Is Cross-Origin-Resource-Policy redundant and strictly worse than doing such enforcement using Sec-Metadata? (The FAQ asks the opposite question.)

Another follow-up question: Similarly, is this a better replacement for CSP frame-ancestors and X-Frame-Options? (#10 (comment) mentions X-Frame-Options but the FAQ doesn't.)

The type of problems I am interested in solving: (1) Reducing DoS risks for underpowered servers that usually serve lightweight traffic but occasionally need to serve expensive resources. (2) minimizing side-channel leakage from cross-site/origin requests by preventing the response from being generated on the server in the first place and preventing it from being sent on the wire, which Cross-Origin-Resource-Policy does not do.

[arturjanc]

Does this work? In particular, would this have the the effect as Cross-Origin-Resource-Policy: same-site or Cross-Origin-Resource-Policy: same-origin, but with the added benefit that the server can avoid sending a the content in a response that would otherwise be ignored under the analogous Cross-Origin-Resource-Policy?

Yes -- in fact, that was one of the main ideas behind the approach based on request headers.

Is Cross-Origin-Resource-Policy redundant and strictly worse than doing such enforcement using Sec-Metadata?

Not really. CORP doesn't offer the same protections as restrictions based on Sec-Fetch headers (e.g. it cannot defend against CSRF), but it can be used as a static response header without requiring server-side logic to decide whether to respond to a request. As such, CORP seems like a reasonable fit for smaller applications; I see the two features as complementary.

Similarly, is this a better replacement for CSP frame-ancestors and X-Frame-Options?

Same as above. For some apps, we're hoping to use both server-side and client-side restrictions against iframing, i.e. in addition to sending X-Frame-Options we might disallow cross-site Sec-Fetch-Mode: nested-navigate.

(2) minimizing side-channel leakage from cross-site/origin requests ...

This is also one of the main motivations of this feature :) We tried to capture some of this in https://arturjanc.com/cross-origin-infoleaks.pdf though it probably doesn't go into sufficient detail...

[mikewest]

Brian, I'm going to close this out, as I don't think there's a concrete addition to the spec that would fall out of it. If you disagree, please do reopen and help me out with some text that you think could clarify things!