Content-Security-Policy now uses 'strict-dynamic'

From v3.3.0.beta1, Discourse implements a ‘strict-dynamic’ Content Security Policy (CSP). This will eliminate the need for manual CSP config, and will greatly improve compatibility with external tooling like tag-managers and advertising.

As a site administrator, you don’t need to do anything. The change will take effect automatically, and any external scripts you’re using will keep working.

No changes are required for themes. A small number of plugins [1] may need a small tweak for compatibility with this change (e.g. 1, 2).

Forums which previously disabled CSP for compatibility with external scripts should now be able to re-enable it without any issues or configuration effort.

For the technical details, check out this topic:

For now, it is still possible to switch back to the old system by disabling the ‘content security policy strict dynamic’ site setting. If you have any reason to do this, please let us know!


From v3.3.0.beta3, we’ve made the ‘strict-dynamic’ keyword a compulsory part of our CSP. The ‘content security policy strict dynamic’ site setting has been removed and the ‘content security policy script src’ site setting has been updated to only store valid values.

For admins, you should be able to find the previous value of the ‘content security policy script src’ site setting from your site’s Staff Action Logs (https://<site_url>/admin/logs/staff_action_logs?filters=%7B%22action_name%22%3A%22change_site_setting%22%2C%22action_id%22%3A3%2C%22subject%22%3A%22content_security_policy_script_src%22%7D - Replace <site_url> with your site’s base URL).


  1. technically: those which introduce <script> elements via register_html_builder or an erb template ↩︎

25 Likes

How can I configure 'unsafe-eval' after this change like before?

No change there - you can still add ‘unsafe eval’ (with the quotes) to the content security script src site setting.

2 Likes

I saw that the description of the content security script src setting states that enabling content_security_policy_strict_dynamic will ignore this setting, so I came here to consult.

2 Likes

The description says

Host sources will be ignored when content_security_policy_strict_dynamic is enabled.

The important bit there is “Host sources”. ‘unsafe-inline’ is not a host source, so it is still supported.

That said, I totally agree this is confusing. Given the success of the strict-dynamic rollout, we’re planning to remove the old system. Once we do that, we can automatically remove all host-sources from the list, and things will be much simpler for admins. :rocket:

4 Likes

OK, thanks for the clarification.

3 Likes