Intent to Implement and Ship: Cross-Origin Resource Policy

[Łukasz Anforowicz]

Intent to Implement and Ship: Cross-Origin Resource Policy

Contact emails

luk...@chromium.org, cr...@chromium.org

Explainer

N/A - Cross-Origin-Resource-Policy is already part of Fetch spec (prior to being included in the spec, this feature was discussed in https://github.com/whatwg/fetch/issues/687 around Mar-Jun 2018).

Design doc/Spec

Spec link: https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header

Summary

“Cross-Origin-Resource-Policy” response header allows http servers to ask the browser to block cross-origin or cross-site embedding of the returned resource.  It is complementary to the Cross-Origin Read Blocking feature and is especially valuable for resources not covered by CORB (which only protects HTML, XML and JSON).

Motivation

“Cross-Origin-Resource-Policy” is currently the only way to protect images against Spectre attacks or against compromised renderers (both of which can circumvent the opaqueness of cross-origin images).  In the future Sec-Fetch-Site might offer another, complementary defense mechanism.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Public support (when discussing https://github.com/whatwg/fetch/issues/687)

Safari: Shipped (in Q2 2018)

Web / Framework developers: Some positive support.

Ergonomics

N/A - this is a http response header (with quite restricted syntax).

Activation

N/A

Debuggability

N/A - can just use DevTools Network panel.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Yes - see wpt/fetch/cross-origin-resource-policy/...

Link to entry on the feature dashboard

https://www.chromestatus.com/features/4647328103268352

Requesting approval to ship?

Yes - the change is small and I’d like to ship enabled-by-default immediately.

[Mike West]

LGTM. This is a reasonable mitigation against a few different attack vectors that I expect a reasonable subset of developers to be able to easily opt-into for sensitive resources. I'm in favour of shipping it quickly, matching Safari's existing behavior.

That said, I recall +Artur Janc suggesting that some bits and pieces of the discussion in the linked GitHub issue would make sense for a v2. Is there any plan for that work in the future?

-mike

[Łukasz Anforowicz]

On Tue, Jan 22, 2019 at 7:04 AM Mike West <mk...@chromium.org> wrote:

LGTM. This is a reasonable mitigation against a few different attack vectors that I expect a reasonable subset of developers to be able to easily opt-into for sensitive resources. I'm in favour of shipping it quickly, matching Safari's existing behavior.

Thanks Mike!

 

That said, I recall +Artur Janc suggesting that some bits and pieces of the discussion in the linked GitHub issue would make sense for a v2.

I assume that you are mostly referring to https://github.com/whatwg/fetch/issues/760 which wants to make Cross-Origin-Resource-Policy accept literal origins?

 

Is there any plan for that work in the future?

Hmm... this is a very good prioritization question.  I think the answer depends on 1) how often in practice sensitive resources need to be exposed cross-site but only to specific origins (this scenario is not addressed by v1 of Cross-Origin-Resource-Policy) and 2) whether this problem is best solved by working on v2 of Cross-Origin-Resource-Policy VS by working on finalizing and implementing something like Sec-Fetch-Site.  I hope that you and aaj@ can provide some guidance here.

[Artur Janc]

On Tue, Jan 22, 2019 at 5:32 PM Łukasz Anforowicz <luk...@chromium.org> wrote:

On Tue, Jan 22, 2019 at 7:04 AM Mike West <mk...@chromium.org> wrote:

LGTM. This is a reasonable mitigation against a few different attack vectors that I expect a reasonable subset of developers to be able to easily opt-into for sensitive resources. I'm in favour of shipping it quickly, matching Safari's existing behavior.

Thanks Mike!

 

That said, I recall +Artur Janc suggesting that some bits and pieces of the discussion in the linked GitHub issue would make sense for a v2.

I assume that you are mostly referring to https://github.com/whatwg/fetch/issues/760 which wants to make Cross-Origin-Resource-Policy accept literal origins?

 

Is there any plan for that work in the future?

Hmm... this is a very good prioritization question.  I think the answer depends on 1) how often in practice sensitive resources need to be exposed cross-site but only to specific origins (this scenario is not addressed by v1 of Cross-Origin-Resource-Policy) and 2) whether this problem is best solved by working on v2 of Cross-Origin-Resource-Policy VS by working on finalizing and implementing something like Sec-Fetch-Site.  I hope that you and aaj@ can provide some guidance here.

I thought about this and my guess is that it could be a bit too early to add origin-level granularity to CORP. It would likely be useful to gauge developer interest and see if the restriction to same-origin / same-site is an obstacle to adoption in the scenarios where developers are hoping to deploy CORP. In the absence of feedback from developers perhaps we shouldn't prioritize it, even if the idea conceptually makes sense (which it hopefully does) ;-)

The main reason I say this is that CORP was meant as an simple declarative mechanism that could offer sites whose resources aren't loaded cross-site some protections from Spectre. Based on the comments we got from engineers working on larger applications (e.g. in https://github.com/w3ctag/design-reviews/issues/280#issuecomment-440896562) I expect that they would be more likely to pursue a server-side approach via Fetch Metadata headers. If smaller / more self-contained sites are well served by CORP v1, and larger applications are more likely to use Fetch Metadata, then the part of the spectrum of application sizes that is served by a more flexible CORP v2 may indeed be fairly low.

Ideally, we'd ship an MVP for both mechanisms, track adoption, and listen to developer feedback to understand their pain points -- at least then we'll have some data to back up our hunches ;)

[Łukasz Anforowicz]

+tkent@ and jochen@

Any other blink/API_OWNERS who might want to chime in with questions and or LGTMs? :-)  I am open to feedback from all API_OWNERS, but I've tried specifically adding tkent@ and jochen@ to CC, since implementing Cross-Origin-Resource-Policy brings Chrome closer to Fetch spec conformance (and tkent@ has #Conformance as part of his mission) and improves web security against Spectre attacks (and AFAIR jochen@ was also involved in Chrome Security work in the past).  FWIW, the CL is almost ready to land - see https://crrev.com/c/1416813.

Thanks,

Lukasz

[Philip Jägenstedt]

LGTM2, this seems pretty straightforward with Safari already having shipped it and the spec work being done.

In https://staging.wpt.fyi/results/fetch/cross-origin-resource-policy?run_id=5844727341514752&run_id=6163721139257344&run_id=6582181900058624&run_id=4697720035999744 it looks like Safari is a fair bit greener than Chrome. Can you look into that? If these are the exact tests for the feature being shipped, then ideally all failures should be accounted for, although not necessarily fixed.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9dc86bf0-edd2-4202-80b6-b83578b0eb34%40chromium.org.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYc_t%3DhK8DQPsJyRi5gts7nz4fOWrMnJdQ7APr4hopRN8A%40mail.gmail.com.

[Łukasz Anforowicz]

Thanks for reviewing this everyone!

I also wanted to say that I was very happy that when implementing this feature I could rely on already existing, comprehensive Web Platform Tests for this feature - big thanks to everyone involved in supporting WPT!

-Lukasz

[Łukasz Anforowicz]

On Thursday, January 24, 2019 at 5:31:14 AM UTC-8, Philip Jägenstedt wrote:

LGTM2, this seems pretty straightforward with Safari already having shipped it and the spec work being done.

In https://staging.wpt.fyi/results/fetch/cross-origin-resource-policy?run_id=5844727341514752&run_id=6163721139257344&run_id=6582181900058624&run_id=4697720035999744 it looks like Safari is a fair bit greener than Chrome. Can you look into that? If these are the exact tests for the feature being shipped, then ideally all failures should be accounted for, although not necessarily fixed.

Chrome didn't implement Cross-Origin-Resource-Policy until today, Jan 24th (r625676), so I expect the WPT dashboards to turn green for Chrome soon (in particular, the link you have sent seems to be testing at r619787 comitted around 21 days ago?).  The failures of Safari should be fixed AFAIK by test tweaks done in https://github.com/web-platform-tests/wpt/pull/14907.  I hope that any current or future unexpected WPT failures will eventually reach me and creis@ thanks to the recently landed //third_party/blink/web_tests/external/wpt/fetch/cross-origin-resource-policy/OWNERS file.