Should not send x-content-security-policy by default

[tunetheweb]

x-content-security-policy was previously supported by some browsers before content-security-policy was fully supported. It is poorly documented and does not support the full feature-set of the standardised content-security-policy.

IE11 is the only commonly in use browser now supporting this, however it only support the sandbox attribute.

We don't support X-Webkit-CSP which was the other older name used by Safari.

I think it's wrong to have this turned on by default and to use the same CSP as the standardised one. Website owners may not notice it's on by default, may assume it has same support as CSP, and will be less likely to test older browsers to see if it breaks.

I'd suggest removing it from the code completely as the standard CSP header is now well supported and standardised. We could also leave it there but in but with a default off status, but I'd really question the value of this. The alternative would be to be able to specify its setting separately to CSP but again I think it's of little value so I say get rid.

This would technically be a breaking change, in that anyone depending on this header will need to change their config to enable it. However, given its poor support, its complete lack of documentation and, the fact that CSP is used in preference to it anyway on any browser that supports that, I think the risk is low and it's preferable to leaving it in place.

Happy to submit a PR for this but wanted to open an issue for discussion first in case anyone disagreed.

[theacodes]

Sounds good. Go for it. :)

…

On Thu, Jul 9, 2020 at 12:55 AM Barry Pollard ***@***.***> wrote: x-content-security-policy was previously supported by some browsers before content-security-policy was fully supported. It is poorly documented and does not support the full feature-set of the standardised content-security-policy. IE11 is the only commonly in use browser now supporting this <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#Browser_compatibility>, however it only support the sandbox attribute <https://stackoverflow.com/a/42940115/2144578>. We don't support X-Webkit-CSP which was the other older name used by Safari. I think it's wrong to have this turned on by default and to use the same CSP as the standardised one. Website owners may not notice it's on by default, may assume it has same support as CSP, and will be less likely to test older browsers to see if it breaks. I'd suggest removing it from the code completely as the standard CSP header is now well supported and standardised. We could also be leave it there but in but with a default off status, but I'd really question the value of this. The alternative would be to be able to specify its setting separately to CSP but again I think it's of little value so I say get rid. This would technically be a breaking change, in that anyone depending on this header will need to change their config to enable it. However, given its poor support, its complete lack of documentation and, the fact that CSP is used in preference to it anyway on any browser that supports that, I think the risk is low and it's preferable to leaving it in place. Happy to submit a PR for this but wanted to open an issue for discussion first in case anyone disagreed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5I4ZZ5TRQU2SAB3JVBLLR2VZXVANCNFSM4OVKQDIQ> .

[tunetheweb]

So happy to remove completely? Or prefer to limit this to turning off by default for now?

[tunetheweb]

FYI @Heisendev who I see added option to disable in #38 and #39

[theacodes]

turning it off by default seems good, yeah? Maybe some strong language in the README about it.

…

On Thu, Jul 9, 2020 at 2:05 AM Barry Pollard ***@***.***> wrote: FYI @Heisendev <https://github.com/Heisendev> who I see added option to disable in #38 <#38> and #39 <#39> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5I4YTLE5C4NZGXBGDD53R2WB57ANCNFSM4OVKQDIQ> .

[tunetheweb]

Just to avoid confusion from anyone coming here later, you agreed to remove in the PR itself:

On second though, I'm happy to remove this.

Thanks!