Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

send Referrer-Policy header #14482

Merged
merged 2 commits into from Jul 14, 2019
Merged

send Referrer-Policy header #14482

merged 2 commits into from Jul 14, 2019

Conversation

Findus23
Copy link
Member

See also #13479, #13204 and #12780

strict-origin only sends a header to the same domain AND origin (so only to HTTPS if Matomo is HTTPS) and no Referer to all other origins.

This does not work in the email report as it seems to be setting headers somewhere else

@Findus23 Findus23 added c: Privacy For issues that impact or improve the privacy. Needs Review PRs that need a code review labels May 25, 2019
@mattab mattab added this to the 3.11.0 milestone Jun 10, 2019
@diosmosis
Copy link
Member

Is there a reason to use strict-origin over no-referrer? (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Directives)

@Findus23
Copy link
Member Author

Findus23 commented Jun 16, 2019 via email

@diosmosis
Copy link
Member

I see, looks like we do use it in some internal requests. Reading the docs more, I think what we want is same-origin, that should prevent it from going to any other domains, and from the examples it looks like the protocol must be the same too. Though the docs aren't really specific about that. I'm not sure if it's really a security risk though.

Only thing I might be worried about is the SAML plugin which uses quite a few redirects when logging a user in. Would need to test that still works and possibly allow some requests to omit the referrer policy.

@Findus23
Copy link
Member Author

Findus23 commented Jun 16, 2019 via email

@diosmosis
Copy link
Member

But if it only sends the referrer to the same matomo instance, and not to any other domain, wouldn't it be more secure than strict-origin? Or am I missing something? Note: in the examples on MDN, the domain is sent on cross-origin requests w/ strict-origin.

@Findus23
Copy link
Member Author

I just checked again and compared with https://scotthelme.co.uk/a-new-security-header-referrer-policy/ and you are right.
The origin in strict-origin refers to only sending the origin as referrer and not to being limited to the same origin.
same-origin is what we want, sending a referrer to the same origin (domain and protocoll) and no referrer otherwise.

@diosmosis
Copy link
Member

It took me a bit to realize as well, there's definitely a naming issue there.

@tsteur
Copy link
Member

tsteur commented Jul 5, 2019

image

tested it... it then sends only the domain as referrer instead of the full URL.
This breaks eg redirectToReferrer feature etc. Is there maybe a different way? Or maybe it's easier to go through most links and check there is noreferrer set as an attribute? Especially in the dataTable? The dataTable links might be enough?

@diosmosis
Copy link
Member

@Findus23 will you have time to update this PR?

sending the full referrer to the same origin, but no referrer for others
@Findus23
Copy link
Member Author

Okay, after another huge confusion I have now updated the PR

@Findus23 Findus23 requested a review from tsteur July 13, 2019 10:12
@tsteur tsteur merged commit e9fef5e into 3.x-dev Jul 14, 2019
@tsteur tsteur deleted the send-referrer-policy branch July 14, 2019 20:08
@Findus23 Findus23 restored the send-referrer-policy branch October 4, 2019 09:48
@diosmosis diosmosis deleted the send-referrer-policy branch November 15, 2019 00:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: Privacy For issues that impact or improve the privacy. Needs Review PRs that need a code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants