Has any thought been given to enabling better Content-Security-Policy headers on the WHM, cPanel, and webmail interfaces by default?
I see threads in the forums about how to setup the Content-Security-Policy headers in the
but when you do that, it appears to apply to the whm.mydomain.com, cpanel.mydomain.com, and webmail.mydomain.com interfaces as well.
I was able to work around this by using the expression conditional like below, but it still leaves those important interfaces 'unprotected' from cross site scripting injection.
After some toying around I found a set of options that appear to avoid breaking the cpanel interfaces, but they are far less than optimal since they require
I also tried using the Tweak option of
but that does not appear to do anything to the web interfaces that are actually important.
It would be nice if the cpanel and webmail interfaces were built such one of 3 things were present (in order of easiest to most desirable):
I see threads in the forums about how to setup the Content-Security-Policy headers in the
Code:
pre_main_global.conf
I was able to work around this by using the expression conditional like below, but it still leaves those important interfaces 'unprotected' from cross site scripting injection.
Code:
Header always set Content-Security-Policy "default-src 'self'; \
script-src 'self' 'strict-dynamic'; \
style-src 'self' 'strict-dynamic'; \
img-src 'self' 'strict-dynamic'; \
object-src 'none'; base-uri 'none';" \
"expr=%{HTTP_HOST} !~ m#(webmail|cpanel|whm)\..*#"
Code:
'unsafe-inline' 'unsafe-eval'
Code:
Enable Content-Security-Policy on some interfaces
It would be nice if the cpanel and webmail interfaces were built such one of 3 things were present (in order of easiest to most desirable):
- If the cpanel applications setup the specific header allows that were needed so one could set a global policy and have it overridden such that these sites aren't broken.
- That they didn't require those unsafe directives by removing the use of inline script and styles
- It would be even more optimal if the applications were enhanced to support 'nonce' in the script and style references and automatically injected 'nonce' in the Content-Security-Policy headers.
Last edited by a moderator: