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
Bug 1370855 - Restrict Referer to same-origin #855
Conversation
@@ -561,6 +561,10 @@ sub header { | |||
# the MIME type away from the declared Content-Type. | |||
$headers{'-x_content_type_options'} = 'nosniff'; | |||
|
|||
# Add Referrer-Policy (sic) header to prevent browsers sending | |||
# Referer (sic) headers to external websites. | |||
$headers{'-referrer_policy'} = 'same-origin'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please consider adding a backup referrer policy, for browsers that don't support 'same-origin'; for example, the below approach probably works to block older browsers from transmitting any referrer at all unless they support the new same-origin policy:
Referrer-Policy: same-origin, no-referrer, none
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would cause more issues than it solves. It would set the document policty to any one of the three values at random (as per the standard algorithm that doesn’t specify a sorting order).
I did a quick check, and not a single website in the HTTP Archive has the Referrer-Policy
value of same-origin, no-referrer, none
. I ran out of credits there just now so I can’t check if any value at all contains a comma.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The algorithm for Referrer Policy does specify an order:
https://www.w3.org/TR/referrer-policy/#unknown-policy-values
So Referrer-Policy: no-referrer, strict-origin-when-cross-origin
is perfectly valid, as is the policy above.
Because of the move to Mojolicious, we have a much better place to apply headers that will work for both the old parts of the code (CGI) and all future code. In addition, this could be accomplished with a plugin: https://metacpan.org/pod/Mojolicious::Plugin::SecurityHeader To do this, you'd add |
Using that plugin will actually solve this bug and a bunch of other bugs, some of which have not been filed yet. |
Works for me! (And thank you for considering it.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good enough for now. we'll need to add this using either SecurityHeaders plugin, or manually with a before-request hook, eventually.
@da2x Thanks for contributing this! It should be live sometime next week, Tuesday or Wednesday at the latest. |
No description provided.