Issue metadata
Sign in to add a comment
|
Referrer-Policy:Same-Origin Fails
Reported by
johnmcor...@gmail.com,
Sep 21 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: 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
,
Sep 25 2017
@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!
,
Sep 25 2017
,
Sep 25 2017
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
,
Sep 26 2017
@estark: can you please take a look and please provide an update as per the above comments. Thanks.!
,
Oct 3 2017
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?
,
Oct 4 2017
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
,
Oct 4 2017
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.
,
Oct 4 2017
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
,
Oct 4 2017
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 |
|||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Sep 21 2017Components: Blink>SecurityFeature