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

Issue 767398 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Referrer-Policy:Same-Origin Fails

Reported by johnmcor...@gmail.com, Sep 21 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

Steps to reproduce the problem:
1. Set Referrer-Policy to same-origin
2. Browse to website (https://edinburgh.axiellspark.co.uk
3. Receive a 400 error on API call.  No console errors 
4. Set Referrer-Policy to strict-orgin
5. Browse to same site.
6. Can access site

What is the expected behavior?
From our understanding of same-origin and strict-origin, if strict-origin works so should same-origin.

What went wrong?
See reproducable steps, as far as we can tell following update to Chrome v61 the same-origin declaration is not working correctly in the browser.  Strict-Origin works OK.  Previously would see console warning if policy was preventing access.

Did this work before? Yes 60

Does this work in other browsers? Yes

Chrome version: 61.0.3163.91  Channel: stable
OS Version: 10.0
Flash Version: 

Although I've said it worked in v60, I do recognise that the policy wasn't fully implemented in v60
 
Cc: ligim...@chromium.org est...@chromium.org
Components: Blink>SecurityFeature
Lopping to feature owner of  Issue 619228 .
@Reporter: could you please let us know how to set Referrer-Policy to same-origin on Chrome.

Note: Tried searching over internet regarding this and got product forum posts stating "Chrome doesn't allow 'same-origin' as Referrer-Policy header value".  

Appreciate your help

Thanks!
Cc: sc00335...@techmahindra.com vamshi.k...@techmahindra.com
Components: -Blink>SecurityFeature Blink>SecurityFeature>Referrer
Labels: Triaged-ET Needs-Triage-M61
Hi

As far as I understand the missing directives for the referrer policy were
added in v61.  See
https://bugs.chromium.org/p/chromium/issues/detail?id=627968

Not withstansing the functionality has changed between v60 and v61.  Cant
get to our site when same-origin is set, no errors just fails to load.
However strict-origin succeeds when we set response header.  My
understanding of dirextive is that if strict works so should same but the
reverse is not true.

To answer your question, I'm not sure you czn set on Chrome as its a
rssponse header, you set on source not client.  Our source is IIS8
Cc: ranjitkan@chromium.org
Labels: Needs-Feedback
@estark: can you please take a look and please provide an update as per the above comments.

Thanks.!
There might be some misunderstanding about what the Referrer-Policy header does. Setting a Referrer-Policy header shouldn't affect whether the website can be accessed or not. Is there a test page available where you've set the same-origin policy where you see the page fail to load?
I completely agree that setting the referrer-policy shouldn't stop a site
being accessed, I may have made the wrong statement, the page loads but for
some reason the same-origin header is blocking an API that strict-origin
permits, which does not make sense.

I've changed our test site to same-origin - you can see this at
https://sparktest.axiellspark.co.uk

If you want to see behavior with strict-origin - you can see this at
https://spark.axiellspark.co.uk
Sorry, I should add that this will be changed back to strict-origin on
Monday 9th October as will be used for testing that week.
Project Member

Comment 9 by sheriffbot@chromium.org, Oct 4 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Unconfirmed)
Thanks for the test case. This looks like it's working as expected. The API must be doing some kind of referer checking and failing the request when no referer is present.

You can see the definition of the different policies here: https://w3c.github.io/webappsec-referrer-policy/#referrer-policies

For a same-origin policy, no Referer header will be sent on cross-origin requests, and the API seems to be refusing to respond when no Referer is present.

Sign in to add a comment