Consider asserting a Cross-Origin-Resource-Policy?

[mikewest]

Hey folks! Hopefully this is a reasonable repository for requests like this one. :)

Cross-Origin-Resource-Policy (CORP) is an HTTP response header that asserts a scope in which a given resource is allowed to be embedded. Today, the default for all resources is to allow cross-site loads, which unfortunately creates the conditions for side-channel attacks via Spectre, et al. With this background, browser vendors are interested in changing this default generally in the long-term, and in the short-term will allow developers to require explicit opt-in via Cross-Origin-Embedder-Policy. This opt-in will be a prerequisite for some particularly interesting APIs like SharedArrayBuffer.

To support this migration, it would be ideal if y'all could begin adding this assertion explicitly to resources that are expected to be used by various sites out there on the internet (e.g. by sending a Cross-Origin-Resource-Policy: cross-origin header). This should be a no-op in the status quo, and will ensure that y'all aren't blocking developers from opting-into Cross-Origin-Embedder-Policy (and therefore exciting new APIs).

If there's any more context I can give you about this set of features, I'd be happy to chat!

[MartinKolarik]

Hi, thanks for the heads-up. Since we already serve access-control-allow-origin: *, is there any use case where this new header would be needed as well? It seems to me that wouldn't make much sense and the COEP introduction chapters says:

responses must either assert a Cross-Origin-Resource-Policy header which allows the embedding, or pass a CORS check

[mikewest]

Hi! Thanks for taking a look!

Since we already serve access-control-allow-origin: *, is there any use case where this new header would be needed as well?

ACAO: * only takes effect for requests that were made as CORS requests, and which explicitly dropped credentials. That is, you're entirely correct that <script ... crossorigin="anonymous"> will continue working, but <script> will fail for developers who opt-into COEP.

You could determine how many folks are making CORS-enabled requests by taking a look at incoming Sec-Fetch-Mode headers in browsers that support Fetch Metadata. I suspect you'll see a mix of cors and no-cors requests. The former will continue working, the latter will not.

HTTP Archive shows* ~243k hosts making cross-site, no-cors requests to cdn.jsdelivr.com, and ~42k making cors requests.

*Query:

SELECT
  requestHost,
  requestMode,
  COUNT(*) as distinctHosts
FROM (
    SELECT DISTINCT
        NET.HOST(url) AS requestHost,
        NET.HOST(page) AS pageHost,
        REGEXP_EXTRACT(payload, r'(?i)sec-fetch-mode:\s*([a-z0-9_\/-]+)') AS requestMode
    FROM
        `httparchive.requests.2020_03_01_desktop`
    WHERE
        REGEXP_EXTRACT(payload, r'(?i)sec-fetch-site:\s*([a-z0-9_\/-]+)') = "cross-site"
)
GROUP BY
  requestHost,
  requestMode
HAVING
  distinctHosts >= 1000
ORDER BY
  distinctHosts DESC

[MartinKolarik]

Thanks for the clarification. We'll add this in the near future.

[mikewest]

Great to hear, thank you! FYI: BootstrapCDN rolled this out last week (jsdelivr/bootstrapcdn#1495). Thus far, nothing's exploded. :)

[mikewest]

Friendly ping. I'd also point to https://resourcepolicy.fyi/ as hopefully helpful context. :)

[MartinKolarik]

@mikewest we'll get to this in 2 - 3 months, as I understand, it isn't necessary right away.

[MartinKolarik]

The header is now being sent by our origin servers: https://cdn.jsdelivr.net/npm/jquery. We didn't purge all the caches around the world, so it'll propagate over time (or we'll purge later to update everything immediately if needed).

[kweij]

When requesting a resource over http I get a 307 Temporary Redirect to the https URL because of the HSTS configuration. This is fine, but this 307 response does not have a CORP header. When the initiator of the request to the CDN (the base html page) has the header Cross-Origin-Embedder-Policy: require-corp, Chrome (at least) doesn't accept the 307 because of the missing CORP header:

^{Chrome blocking 307 with missing CORP header}

I am very new to all these types of headers and configuration, but because of this issue I have, I had to dive into it. Now it seems to me that jsdelivr's 307 responses are missing the CORP header and I think these should be added. Am I correct?

^{As for Firefox: it seems fetch the resources directly via https, for some reason, and therefor doesn't has this exact issue.)}

[MartinKolarik]

The 307 is an "internal" response issued by Chrome, we can't change anything about it. If it causes an issue with CORP, I suppose you'll have to use HTTPS explicitly (as you should anyway) to avoid the redirect.

[mikewest]

It's worth filing a bug against Chromium here (https://crbug.com/new). You ought to be loading the https URL, but there's no harm in allowing the internal HSTS redirect to pass through.

[kweij]

@MartinKolarik, offcourse on production I use https, but on local development I don't have a self-signed certificate to use https - and that's probably the case for many other dev environments.

@mikewest, I will. I had my doubts about the behavior of Chrome after I noticed that Firefox handles it differently.

Thanks for the replies!

[MartinKolarik]

@kweij the issue is related only to requests that you make to jsDelivr (or other third parties). You can load your own content via HTTP locally, if you explicitly use HTTPS just for jsDelivr, you should be fine.

[kweij]

@MartinKolarik, yes, your are right - this has nothing to do with my local environment. I was confused only because the resources are loaded using the protocol-less URL ("//cdn.jsdelivr.net/...").

[kweij]

@mikewest, good call on the Chrome bug. I've reported it and it's fixed already: https://bugs.chromium.org/p/chromium/issues/detail?id=1287500