New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 11 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 25
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 3
Type: Feature



Sign in to add a comment
link

Issue 853723: Implement Cross-Origin-Resource-Policy

Reported by annevank...@gmail.com, Jun 18 2018 Project Member

Issue description

See https://github.com/whatwg/fetch/pull/733.

web-platform-tests tests are in fetch/cross-origin-resource-policy.
 

Comment 1 by dtapu...@chromium.org, Jun 18 2018

Components: Blink>SecurityFeature

Comment 2 by mkwst@chromium.org, Jun 19 2018

Cc: lukasza@chromium.org creis@chromium.org
Components: Internals>Sandbox>SiteIsolation
Labels: -Type-Bug OS-Android OS-Chrome OS-Linux OS-Windows Type-Feature
Owner: nasko@chromium.org
Status: Assigned (was: Unconfirmed)
CCing folks involved in the conversations around this feature.

Nasko, can you triage this into your backlog?

Comment 3 by lukasza@chromium.org, Jun 19 2018

Early thoughts:

- I think CORP is sufficiently different from CORB (also looks at intermediate redirects I think, results in a network error), that it might make sense to
    1) implement a separate //services/network/cross_origin_resource_policy.h/.cc
       that would expose ShouldBlock(net::URLRequest& request,
                                     const ResourceResponse& response,
                                     ...excluded_initiator_scheme???...).
    2) hook it up to URLLoader::OnReceivedRedirect and URLLoader::OnResponseStarted
       as well as equivalents in the ResourceHandler world

- When implementing cross_origin_resource_policy.h might need to reuse some things
  from cross_origin_read_blocking.h (e.g. IsValidCorsHeaderSet) - they should be
  easy to extract into something like cross_origin_policy_helpers.h

- QUESTION: Should CORP apply to requests initiated by
    1) content scripts / extensions
    2) plugins
    3) file: origins
    4) browser process
  I think the answer to all of these should be "yes!".

Comment 4 by lukasza@chromium.org, Jun 19 2018

Cc: rdevlin....@chromium.org
+rdevlin.cronin@ for the extensions discussion above

Comment 5 by nasko@chromium.org, Jun 20 2018

mkwst@ can you help me understand the priority of when we want this implemented? Our team is currently lacking any spare cycles, so I'm not sure we will be able to get to this in the near term. In comment #3, lukasza@ has provided enough guidance that I think any other team/dev should be able to implement it and we will be happy to review/consult.

Comment 6 by mkwst@chromium.org, Jun 20 2018

Cc: arturjanc@google.com
nasko@: I think the priority depends a bit on whether developers are actively going to implement this based on the support that Apple's implemented, and Mozilla's apparently looking into. There's a WebAppSec call tonight, and I'll ask whether any developers are lined up already.

Speaking of developers: Artur! You've suggested in the past that Google's security team probably wouldn't implement this unless it had origin-based lists. Are there endpoints where your team would actually be able to use the `same-origin`/`same-site` distinction? Or do you need more before you can ship it on Google properties?

Comment 7 by mkwst@chromium.org, Jun 21 2018

Cc: -arturjanc@google.com a...@google.com
Actually adding Artur, sorry. Wrong LDAP. :)

Comment 8 by a...@google.com, Jun 21 2018

We don't have immediate plans to deploy CORP, not so much for the lack of origin-based lists but the underlying problem with visibility of the requesters of resources. Basically, for an arbitrary application on foo.google.com it's possible that its resources are loaded cross-site in the following scenarios:
- ccTLDs (foo.google.co.uk)
- Other Google-owned domains (youtube.com)
- Test / staging instances loading production resources (localhost, other custom domains)  

To use CORP, even with origin-based flexibility, we would first need to enumerate cross-origin requesters of all resources in a given application, which is difficult and doesn't always work; e.g. we could try to collect the Referer header, except that we don't get it from applications which hide it with the Referrer Policy.

I imagine our ongoing work on Sec-Metadata will give us some visibility into which applications have resources which are only loaded same-origin/same-site. In the unfortunate event of not all browsers immediately shipping Sec-Metadata we could use information we get from the request header to set a CORP response header with corresponding logic.

Overall, as a developer, I would be happy to see both CORP and Sec-Metadata broadly supported by browsers. So I think Chrome should implement CORP, Anne should implement Sec-Metadata in Firefox and everyone wins ;-)

Comment 9 by awhalley@chromium.org, Jun 23 2018

Cc: awhalley@chromium.org

Comment 10 by creis@chromium.org, Jan 15

Cc: nick@chromium.org palmer@chromium.org
 Issue 837379  has been merged into this issue.

Comment 11 by creis@chromium.org, Jan 15

Cc: -nick@chromium.org nasko@chromium.org
Owner: lukasza@chromium.org
Sounds like lukasza@ is looking into implementing this.  Thanks!

Comment 12 by lukasza@chromium.org, Jan 17

Status: Started (was: Assigned)
I have a WIP CL @ https://chromium-review.googlesource.com/c/chromium/src/+/1416813
(note that it depends on not-yet-landed https://github.com/web-platform-tests/wpt/pull/14907)

Comment 13 by bugdroid, Jan 24

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/78f93959597e9128cbed353a56588ec4099b20dc

commit 78f93959597e9128cbed353a56588ec4099b20dc
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Thu Jan 24 16:38:59 2019

Implementing support for 'Cross-Origin-Resource-Policy' response header.

See also
https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header

Bug:  853723 
Change-Id: I1bafc0c75c84dc0fff36fcf92fab34ea4206d689
Reviewed-on: https://chromium-review.googlesource.com/c/1416813
Commit-Queue: Ɓukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#625676}

Comment 14 by lukasza@chromium.org, Jan 25

Status: Fixed (was: Started)

Comment 15 by jmedley@google.com, Jan 29

Please remember to update the Chrome Status entry. https://www.chromestatus.com/features/4647328103268352

Comment 16 by lukasza@chromium.org, Jan 29

Labels: Target-73
RE: #c15: jmedley@

Thanks for the reminder - I've updated the Chrome Status entry to indicate that Cross-Origin-Resource-Policy is shipping in M73.

Sign in to add a comment