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

**URL:** <https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172>\
**Category:** Announcements\
**Created:** [March 7, 2024, 3:24pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172 "2024-03-07T15:24:39Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)\
**Post date:** [March 7, 2024, 3:24pm UTC](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172/1 "2024-03-07T15:24:39Z")

</div>

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](https://github.com/discourse/discourse-client-performance/commit/31b6a21f26), [2](https://github.com/paviliondev/discourse-multilingual/commit/7ab8a6bb2c)).

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:

> [@(Superseded) Experimenting with a 'strict-dynamic' Content Security Policy (CSP)](https://meta.discourse.org/t/experimenting-with-a-strict-dynamic-content-security-policy-csp/295603):
>
> We’re experimenting with a new ‘strict-dynamic’ CSP, which should make it much easier to integrate themes, plugins and external scripts with Discourse in a secure way. You can try out the new mode by enabling the ‘content security policy strict dynamic’ site setting. Please let us know if you have any feedback! We hope to make this the default in the near future, and will make an #announcements topic as we get closer to that goal. For more information, see below: scroll Background [Back in…](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243)

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

---

_[View the full topic](https://meta.discourse.org/t/content-security-policy-now-uses-strict-dynamic/298172)._