Recently a client was asking us to implement Content-Security-Policy and/or X-Frame-Options in our addon.
After some discussion we still don’t have a clear idea on the matter. Does it make sense to implement CSP in Confluence Cloud apps?
Our guess is that our frames won’t work out of context unless you have a valid signed jwt. So we should be safe there.
Does Atlassian have any suggestion or answer on this matter?
Regards,
Hugo
Not Atlassian but it’s not a bad thing to implement - it keeps you honest to yourself at least (since you will know what restrictions/capabilities you need to have…).
Depending on how you implement it - it does give you one more security knob to turn).
Does the client have specific compliance requirements or any particular risk they would like to address? While the X-Frame-Options header makes little sense for cloud apps given they must be framed, you can use CSP’s frame-ancestors directive as additional layer of defense to ensure that your content isn’t embedded into unexpected sites. At this time, implementing CSP is not part of the security requirements for cloud apps, but we certainly encourage it as a defense in depth mechanism.
Recommendations outside the formal requirements like this would make a lot of sense to collect in a common place, especially in the Connect frameworks like ACE or the ACE template. I love seeing clear answers like this, but the chances of all developers finding them strewn about CDAC is hopeless.
You cannot meaningfully restrict the allowed frame ancestors if the app is to support custom domains, at least not if the value of the directive is static.
It should be possible to evaluate the tenant context given by the JWT and set the header dynamically, but that’s more costly to configure/implement. Is that approach advisable/encouraged?
As I understand it, the main motivation of an attacker to embed a UI module on another domain is to make an unsuspecting user do something in the context of their session through click-jacking or something similar. The UI module won’t work without a valid JWT in the URL, so the attacker would have to have that. In most of our apps, the user’s credentials for calls to our back end are derived from that JWT. If an attacker has a valid JWT, they would most likely already have all they need. So it’s not clear to me that restricting the frame ancestors would provide any additional security benefits. However, I’d be happy to hear about scenarios where it would.
@JanaGeddis The custom domain setup is also not compatible with the current version of Atlassian Connect Express, as that framework also restricts the allowed domains.