Hello, Atlassian Developer Community!
As part of the Confluence 10.0 platform release, we’re implementing and adopting a Content Security Policy (CSP). CSP instructs the web browser what content (such as scripts, iframes, or images) is allowed to run on the page. Restricting what content is permitted can help protect users against a range of client-side application security threats.
The primary use case for CSP is to control which resources, particularly JavaScript resources, a document is allowed to load. This is mainly used as a defense against cross-site scripting (XSS) attacks, in which an attacker can inject malicious code into the victim’s site.
We will enable the script-src CSP header. This will be a report-only feature in Confluence 10. In this mode, the system logs violations without blocking any resources. This allows monitoring and gathering data on potential security issues without affecting the user experience. We also provide additional utilities to set up nonces and even add your own origins to the CSP header. We will enforce CSP completely in Confluence 11.
Potential impact on security and reliability
- Prevention of XSS attacks: CSP can significantly reduce the risk of cross-site scripting (XSS) attacks.
- Protection against code injection: CSP can also help prevent other types of code injection attacks, such as SQL injection and server-side request forgery (SSRF).
- Mitigation of data exfiltration: By restricting the resources that can be loaded on a page, CSP can help prevent data exfiltration attacks where sensitive information is stolen from the application.
- Reduced downtime: CSP can help prevent malicious code from disrupting the normal operation of Confluence, reducing the risk of downtime and outages.
- Enhanced stability: CSP can improve the application’s overall stability and reliability by limiting the execution of untrusted scripts.
Customer experience benefits
- Enhanced security: CSP can provide customers with a more secure environment, reducing the risk of data breaches and unauthorized access.
- Improved trust: By demonstrating a commitment to security, CSP can help build trust with customers and partners.
- Reduced risk of malware: CSP can help protect customers from malware infections that can compromise their systems and data.
Take steps to adapt your apps to CSP
As Marketplace partners, you need to make the following JavaScript changes for your apps:
- Remove JavaScript inline event handlers and
javascript:URLs. - Remove the
eval()method from your JavaScript. - Add additional config in your
atlassian-plugin.xmlin case your JavaScript is coming from external domains.
Test your apps to avoid CSP violations
Any CSP violation reports sent by the browser will be logged for further analysis. To identify and correct CSP violations in your apps, enable the following system properties.
| Sysprop | Description | Default value |
|---|---|---|
enable.csp.violation.logging |
Enables CSP violation reports to a log file. | false (disabled by default) |
csp.enable.nonce.js |
Enable CSP nonce for <script> tags. |
false (disabled by default) |
csp.enable.nonce.css |
Enable CSP nonce for <link rel="stylesheet"> tags. |
false (disabled by default) |
csp.enable.nonce.prefetch |
Enable CSP nonce for <link rel="prefetch"> tags |
false (disabled by default) |
Replace inline event handlers
Ideally, replace inline scripts with external JavaScript.
For example, if you use inline event handlers like below, move the onclick function outside of the expression.
<button onclick="alert('Button clicked!')">Click Me</button>
In the case of inline scripts like the following one, make them external JavaScript.
<script> console.log('This is inline JavaScript inside a script tag.'); </script>
Another option is to provide a nonce like in the following example:
<script nonce="<nonce>"> console.log('This is inline JavaScript inside a script tag.'); </script>
In this example, the nonce can be replaced by a utility Java method that we will be providing you with.
Thanks for being part of this journey!