Not a bug Referrer Policy (CSP) breaks some redirects

[shello]

When a Referrer Policy header is sent with the value "origin" on XenForo pages, some redirects break.

The example policy is:

Content-Security-Policy: referrer origin;

This policy tells the browser to include an HTTP Referer header in requests starting from that page, with the value being the origin only (i.e. protocol + hostname + port), instead of the full URI or not sending this header at all (in case the page is served over HTTP or HTTPS, respectively).

An example of a broken redirect is when a warning is given on a post. If this CSP directive is in place, after warning a user (`actionWarn`) XenForo will redirect the user to the root of the domain instead of redirecting the user back to the content.

There might be other broken redirects, as the function that uses the HTTP Referer header is part of the base Controller (`getDynamicRedirect`).

 

[Mike]

I'm going to have to say that this is generally expected and not in the scope of something we'd be trying to support. When you're manipulating the response (including response headers) like that, it may change the behavior of the application in unexpected ways.

At the least, you should be sending full referrers with the same origin.

 

[shello]

Thanks for your reply, @Mike.

At the moment XenForo supports the default Referrer Policy for both pages served over HTTP and HTTPS, that is, with an HTTP ‘Referer’ containing the full URL of the referrer page and with no HTTP ‘Referer’ at all. These, of course, are part of the HTTP RFCs.
But because of the latter case, in which no HTTP ‘Referer’ is sent, depending on the ‘Referer’ header feels somewhat unnecessary, more so when a `redirect` parameter can already be passed to `actionWarn` with the URL to redirect back to after the action is finished.
I admit I don't understand fully why the 'Referrer' header is used for this case, but not depending on its value at all would open the possibility of supporting the Referrer Policy spec.

Of course, while the argument I’m making in this post might not support why this is a bug (and therefore should be fixed), at least it represents why I thought this would be worth reporting.