Add same-origin referrer-policy header to WP Admin pages

[joostdevalk]

When a user clicks a link in the WP-Admin and goes to another site, the http referrer gets set. That means that site can see in their analytics and in their access logs where the user came from. This means that the location of people's wp-admin folders isn't kept safe. Especially if plugins add important data to the URL, that data is also not kept safe.

The above is why I'm suggesting implementing a referrer-policy header. This header, when set to same-origin, prevents the browser from sending the referrer when going to another site. The referrer _is_ sent when you from one page to the other in the admin, so we can keep using that reliably.

More info:

• ​https://scotthelme.co.uk/a-new-security-header-referrer-policy/
• ​https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

[joostdevalk]

Patch

[anonymized_14169293]

You should consider that some customized servers are sending this header, so it could result in a duplicate header.

[joostdevalk]

Replying to QROkes:

You should consider that some customized servers are sending this header, so it could result in a duplicate header.

Having the header twice will not undo it.

[anonymized_14169293]

Replying to joostdevalk:

Replying to QROkes:

You should consider that some customized servers are sending this header, so it could result in a duplicate header.

Having the header twice will not undo it.

It's not that simple. HTTP RFC2616 available here says:
​https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
"Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded. "

[joostdevalk]

As far as I know, and I'd love to be proven wrong: there's nothing we could do. The default is already set to true as the second parameter for header in the patch, thereby it tries to replace other headers of the same name, resulting from code.

Other than that, the fact that people have and will add headers to output is not something WordPress core can account for...

[peterwilsoncc]

While an existing header through server configuration is a legitimate concern, in this case it's mitigated by being a new spec.

[johnbillion]

+1 for this from me, but I think the header should be output on a hook so it can be unhooked in case a site owner wants to implement an even more strict referrer policy. After a cursory glance, it looks like admin_init might be the only existing hook that's appropriate. Or a new action could be added to the top of wp-admin/admin-header.php.

[johnbillion]

Should this be added to wp-login.php too?

[joostdevalk]

Patch v2

[joostdevalk]

Patch v3

[joostdevalk]

Added a new patch that introduces the function wp_admin_headers, and fires that on admin_init and login_init. This function also allows the policy to be filtered through the admin_referrer_policy filter.

[johnbillion]

I like the look of this.

[johnbillion]

In 41741:

Security: Add a referrer policy header to the admin and login screens.

This sets a referrer policy of same-origin which adds hardening by preventing a referrer being sent from the admin area or login screens to other origins. This helps prevent unwanted exposure of potentially sensitive information that may be contained within URLs.

This change introduces a new filter, admin_referrer_policy, for filtering the referrer policy header value. The header can be disabled if necessary by removing the wp_admin_headers action from the admin_init and login_init hooks.

Props joostdevalk
Fixes #42036