I have been looking for the right setting of CSP (Content-Security-Policy). I couldn't find it so I first tried with
Content-Security-Policy "default-src 'self';
but then my pages were not rendered correctly aymore.
It seems to be workling now with the following setting:
Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data:";
Can anyone confirm this is the expected settings? Can I remove the unsafe-eval from the script?
I'd love some recommendation for this also.
I've been testing CSP lately in our test environment (confluence 6.4.3, jira 7.4.0, apache 2.4.18 proxy), and so far it seems the only way to get it working is to define almost all CSP flags (thanks to https://content-security-policy.com, it has good description of those).
Here's example from one of our subdomain's virtual host config:
Header set Content-Security-Policy " \
default-src 'self' *.mydomain.com; \
script-src 'self' *.mydomain.com 'unsafe-inline' 'unsafe-eval'; \
style-src 'self' *.mydomain.com 'unsafe-inline'; \
img-src 'self' *.mydomain.com data:; \
connect-src 'self' *.mydomain.com; \
font-src 'self' *.mydomain.com; \
object-src 'self' *.mydomain.com; \
media-src 'self' *.mydomain.com; \
frame-src 'self' *.mydomain.com; \
child-src 'self' *.mydomain.com; \
form-action 'self' *.mydomain.com; \
We are using wildcard subdomain in CSP, this seems to allow our two subdomains (jira and confluence) to talk to each other.
We are still getting some errors from jira and confluence admin pages, because both local server instances are trying to load js file from jira.atlassian.com, which is now blocked by CSP. Whether thats fatal or not is still under investigation.
Thanks for you answer. I do not have the subdomain issue as I have mydomain.com/jira and mydomain.com/confluence ;-)
The JS content retrieved from Atlassian should probably be reported as a bug to Atlassian. Imagine one day they have a technical issue, then your "on-premises" instance can also be affected, or worse, if they get hacked, hackers could then inject anything they want straight into your admin console ;-(
If you do raise a bug, provide me the reference I will vote for it ;-)
CSPs are usually set at the reverse proxy in front of a webserver. It sounds like you are using Apache? Our doc doesn't have a recommendation for that setting: Proxying Atlassian server applications with Apache HTTP Server (mod_proxy_http)
CSP recommendations for several proxies, including Apache, are in this third party doc I found: Secure your website with Content Security Policy
I am not sure what the unsafe-eval is or which script it is in. Please let me know more about this question, I will be happy to research it.
Thanks for your answer.
I indeed set the headers at the reverse proxy (NGINX in my case).
Obviously the most secure approach is to use only scripts in external files (as it should be harder to create a file, than inject content in a web page).
@Tero Laihia I got a response from the security team regarding an official recommendation for CSP settings. They let me know that
we do not have a recommendation for CSP settings for our products and that adding in these headers can cause problems with functionality. While you may find a setting that works for a given product version, future updates may break that policy.
Based on this, it sounds like trial and error is the only way to find out what will work in your environment. If your team uses Content Security Policy headers, it makes it more important than ever to test any upgrades on a test system before upgrading Production applications.
Hi my Community friends! For those who don't know me, I'm a product marketer on the Confluence Cloud team - nice to meet you! For those of you who do, you know that I've been all up in your Co...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs