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
Closed: Jan 25
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 3
Type: Feature

Sign in to add a comment

Issue 853723: Implement Cross-Origin-Resource-Policy

Reported by, Jun 18 2018 Project Member

Issue description


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

Comment 1 by, Jun 18 2018

Components: Blink>SecurityFeature

Comment 2 by, Jun 19 2018

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

Nasko, can you triage this into your backlog?

Comment 3 by, 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,
    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, Jun 19 2018

+rdevlin.cronin@ for the extensions discussion above

Comment 5 by, 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, Jun 20 2018

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, Jun 21 2018

Actually adding Artur, sorry. Wrong LDAP. :)

Comment 8 by, 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 it's possible that its resources are loaded cross-site in the following scenarios:
- ccTLDs (
- Other Google-owned domains (
- 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, Jun 23 2018


Comment 10 by, Jan 15

 Issue 837379  has been merged into this issue.

Comment 11 by, Jan 15

Sounds like lukasza@ is looking into implementing this.  Thanks!

Comment 12 by, Jan 17

Status: Started (was: Assigned)
I have a WIP CL @
(note that it depends on not-yet-landed

Comment 13 by bugdroid, Jan 24

Project Member
The following revision refers to this bug:

commit 78f93959597e9128cbed353a56588ec4099b20dc
Author: Lukasz Anforowicz <>
Date: Thu Jan 24 16:38:59 2019

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

See also

Bug:  853723 
Change-Id: I1bafc0c75c84dc0fff36fcf92fab34ea4206d689
Commit-Queue: Ɓukasz Anforowicz <>
Reviewed-by: Charlie Reis <>
Reviewed-by: John Abd-El-Malek <>
Cr-Commit-Position: refs/heads/master@{#625676}

Comment 14 by, Jan 25

Status: Fixed (was: Started)

Comment 15 by, Jan 29

Please remember to update the Chrome Status entry.

Comment 16 by, 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