# Mitigate XSS Attacks with Content Security Policy

**URL:** https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243
**Category:** Site Management
**Tags:** how-to, content-security-policy
**Created:** [December 14, 2018, 4:38pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243 "2018-12-14T16:38:20Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![Discourse](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/discourse/32/148734_2.png) [@Discourse](https://meta.discourse.org/u/Discourse)
#### Post date: [December 14, 2018, 4:38pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/1 "2018-12-14T16:38:20Z")

</div>

> 🔖 This guide explains how to use Content Security Policy (CSP) to mitigate Cross-Site Scripting (XSS) attacks in Discourse. It covers CSP basics, configuration, and best practices.
> 
> 🙋 Required user level: Administrator

## Summary

Content Security Policy (CSP) is a crucial security feature in Discourse that helps protect against Cross-Site Scripting (XSS) and other injection attacks. This guide covers the basics of CSP, how it’s implemented in Discourse, and how to configure it for your site.

## What is Content Security Policy?

Content Security Policy is an added layer of security that helps detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. CSP works by specifying which content sources are considered trusted, and instructing the browser to only execute or render resources from those trusted sources.

XSS remains one of the most common web vulnerabilities. By implementing CSP, Discourse allows scripts only from trusted sources to load and execute, significantly reducing the risk of XSS attacks.

## Discourse’s CSP implementation

As of Discourse version 3.3.0.beta1, Discourse implements a ‘strict-dynamic’ CSP. This approach uses a single `nonce-` value and the `strict-dynamic` keyword in the `script-src` directive. All initial `<script>` tags in core and themes are automatically given the appropriate `nonce=` attribute.

The default policy includes the following directives:

- `script-src`: Specifies valid sources for JavaScripts
- `worker-src`: Specifies valid sources for ServiceWorker scripts
- `object-src`: Blocks the execution of plugins (Flash, Java, etc.)
- `base-uri`: Restricts the URLs for `<base>` elements
- `manifest-src`: Restricts the URLs for web app manifests
- `frame-ancestors`: Controls which sites can embed your Discourse instance in an iframe
- `upgrade-insecure-requests`: Automatically upgrades HTTP requests to HTTPS (included when `force_https` is enabled)

## Configuring CSP in Discourse

### Available settings

- `content_security_policy`: Enables or disables CSP (default: on)
- `content_security_policy_report_only`: Enables CSP Report-Only mode (default: off)
- `content_security_policy_script_src`: Allows you to extend the default [`script-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src)
- `content_security_policy_frame_ancestors`: Enables the [`frame_ancestors` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) (default: on)

### How to enable CSP

1. Navigate to your Admin panel
2. Go to Security settings
3. Find the `content_security_policy` setting and ensure it’s enabled

It’s recommended to start with CSP Report-Only mode to identify any potential issues before fully enabling CSP:

1. Enable the `content_security_policy_report_only` setting
2. Monitor your browser console for CSP violations
3. Address any legitimate violations by extending the CSP as needed
4. Once you’re confident there are no false positives, disable Report-Only mode and fully enable CSP

### Extending the default CSP

If you need to allow additional script sources, you can extend the `script-src` directive using the `content_security_policy_script_src` setting. You can add:

- Hash-sources
- `'wasm-unsafe-eval'`
- `'unsafe-eval'` (use with caution)

For example:

```plaintext
'sha256-QFlnYO2Ll+rgFRKkUmtyRublBc7KFNsbzF7BzoCqjgA=' 'unsafe-eval'

```

⚠ Be cautious when adding `'unsafe-eval'` or other permissive directives, as they can reduce the effectiveness of CSP.

## CSP and third-party integrations

When using third-party services like Google Tag Manager, Google Analytics, or advertising services, you may need to adjust your CSP settings. In most cases with Discourse version 3.3.0.beta1 or later, external scripts should work without additional configuration due to the ‘strict-dynamic’ CSP implementation.

If you encounter issues, you may need to:

1. Identify the required script sources by monitoring your browser console
2. Add the necessary sources to the `content_security_policy_script_src` setting
3. For complex integrations like ad services which load external resources, you might need to enable cross-domain rendering ([Example PR from discourse-adplugin](https://github.com/discourse/discourse-adplugin/pull/201) that does this).

## Best practices

1. Start with CSP Report-Only mode to identify potential issues
2. Gradually tighten your CSP as you resolve legitimate violations
3. Regularly review your CSP settings and adjust as needed
4. Be cautious when adding permissive directives like `'unsafe-eval'` or `'wasm-unsafe-eval'`
5. Keep your Discourse instance updated to benefit from the latest CSP improvements

## FAQs

**Q: I’m seeing many CSP violation reports. Should I be concerned?**  
A: Many CSP violations are false positives, often caused by browser extensions or other unrelated scripts. Focus on addressing violations related to your site’s functionality.

**Q: Can I use CSP with Google AdSense or other ad networks?**  
A: Yes, but you may need to use more permissive CSP settings. Start with Report-Only mode and adjust your settings based on the reported violations.

**Q: How do I troubleshoot CSP issues?**  
A: Use your browser’s developer tools to monitor the console for CSP violation messages. These will help you identify which resources are being blocked and why.

## Additional resources

- [Content Security Policy (CSP) - HTTP | MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
- [Content security policy &nbsp;|&nbsp; Articles &nbsp;|&nbsp; web.dev](https://developers.google.com/web/fundamentals/security/csp/)
- [Content Security Policy Level 3](https://w3c.github.io/webappsec-csp/)
- [Strict CSP - Content Security Policy](https://csp.withgoogle.com/docs/strict-csp.html)
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com/)

> Last edited by @kelv 2024-10-04T06:30:07Z
> 
> > **Check document**
> >
> > Perform check on document:

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [December 20, 2018, 12:55am UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/2 "2018-12-20T00:55:05Z")

</div>

I added a note about this to [our public security.md file](https://github.com/discourse/discourse/blob/master/docs/SECURITY.md) 🎉

---

<div class="post-metadata">

### Author: ![pmusaraj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pmusaraj/32/119489_2.png) [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [January 15, 2019, 4:36pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/3 "2019-01-15T16:36:10Z")

</div>

As of [this commit](https://github.com/discourse/discourse/commit/1c1fd2051f9eaed8b3a20be46cdcf98370dd9043), we’ve turned off CSP violations reports by default because the vast majority of the reported violations are false positives.

To illustrate this, here is a screenshot of logs from a site running Discourse with CSP enabled and reporting enabled (filtered using “CSP Violation”):

 ![958f7da0a11238eca5341673ba67c524bac6be54_2_1380x544](https://global.discourse-cdn.com/meta/original/3X/a/8/a84793d48e242caf49b5fe88cb1572e0c153f2a5.png)

All of the reported violations are not related to the site’s code:

- violations with ‘minisrclink.cool’ or ‘proxdev.cool’ in the URL have nothing to do with Discourse, they’re likely coming from a browser extension
- the Google Analytics violation reports are also not legitimate. They are triggered by Firefox in privacy mode, or Firefox with a privacy extension enabled (like DuckDuckGo Privacy Essentials).
- Violations with ‘inline’, ‘data’ or ‘about’ are triggered by extensions as well. It’s not shown in the screenshot above, but these violations have some more details in the `env` tab of the log. In there, under `script-sample`, some of these violations had code like `BlockAdBlock` or `window.klTabId_kis` or `AG_onLoad`, which come from the AdBlock, Kaspersky, and AdGuard extensions, respectively. (I found this repo: [CSP-useful/csp-wtf/README.md at master · nico3333fr/CSP-useful · GitHub](https://github.com/nico3333fr/CSP-useful/blob/master/csp-wtf/README.md) very useful in helping explain some of these reports.) Some of these violations will have `safari-extension` or `user-script` in the `source-file` variable (again, in `env`), so that points to Safari extensions as the culprit for the violation.

In other words, there’s a lot of noise in CSP violation reports, so it’s not useful to log them at all times. They might be helpful while you are configuring CSP, but the reporting should be off during the normal operation of a site.

A few final notes: if you site is using a tag manager (like Google Tag Manager or Segment) you need to load the site in your browser, and carefully examine the violations in the console. These tools load third-party scripts from third-party domains and/or inline scripts so you need to carefully whitelist each of them using the source URL or the hash of the inline script (Chrome usefully includes the hash of inline scripts in the console error statement).

If your site uses an advertising service (like Google Ad Manager, Adsense, etc.) you probably will have to use a very permissive policy:

 ![image](https://global.discourse-cdn.com/meta/original/3X/0/4/048dd28339b5f74ef6652db6e612b32045e3ccc6.png)

In the screenshot above, the policy allows any script from a `https:` source and any inline script. (In the future, this might be replaced by the [strict-dynamic](https://csp.withgoogle.com/docs/faq.html) keyword, but as of this writing, `strict-dynamic` isn’t supported by Safari or Edge.)

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 3, 2019, 6:03am UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/12 "2019-04-03T06:03:46Z")

</div>

8 posts were split to a new topic: [Protocol-less CDN URLs are problematic](https://meta.discourse.org/t/protocol-less-cdn-urls-are-problematic/113301)

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 12, 2019, 9:16pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/19 "2019-04-12T21:16:54Z")

</div>

Please note that Safari doesn’t understand some parts of CSP, and this is normal:

 ![04%20AM](https://global.discourse-cdn.com/meta/original/3X/4/5/45f8d96da1726a6a187ea93c3819ceb14b70f5da.png)

> You can safely ignore the CSP errors in Safari, you’ll see those on all sites, it just means Safari doesn’t understand `worker-src` and `report-sample` .

I guess we need to wait for Safari to be updated?

---

<div class="post-metadata">

### Author: ![Eduardo\_Braga](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/eduardo_braga/32/110348_2.png) [@Eduardo\_Braga](https://meta.discourse.org/u/Eduardo_Braga)
#### Post date: [January 29, 2020, 8:50pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/21 "2020-01-29T20:50:59Z")

</div>

I’m having trouble configuring, which recommendation?

my forum: forum.meuxbox.com.br

link: [https://meta.discourse.org/t/white-blank-advertisement/140098/10?u=eduardo\_braga](https://meta.discourse.org/t/white-blank-advertisement/140098/10)

 ![CSP](https://global.discourse-cdn.com/meta/original/3X/7/7/7792c2eb8f38f887d247b3c2d7487fef9827cb9e.png)

 ![adsss](https://global.discourse-cdn.com/meta/original/3X/5/9/593afc94b740cfd2cf1eed0e2052227a5d6f2c0f.png)

 ![dominios](https://global.discourse-cdn.com/meta/original/3X/8/4/84a9a074e7dca1037713d1f1839ada238cf549b5.png)

---

<div class="post-metadata">

### Author: ![pmusaraj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pmusaraj/32/119489_2.png) [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [January 29, 2020, 8:54pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/22 "2020-01-29T20:54:26Z")

</div>

It depends on what URLs your ads are requesting. You can look at your browser’s console to see them.

See also the relevant section from the OP:

> [@xrav3nz](#):
>
> #### 4. Third-Party Script / Service Integration
> 
> Different integrations will have different requirements, but can be addressed similarly.
> 
> You could look up the integration’s recommended CSP whitelist, and extend the default CSP accordingly. I suggest simply [turn on CSP Report Only mode in Discourse](#heading--available-settings), and watch your console to determine which resources you’ll need to whitelist to make your integrations work.
> 
> This is especially important when using third-party script bundlers like Google Tag Manager or Segment, because these bundlers might load many third-party or inline scripts. (You might even end up adding `'unsafe-inline'` when using Segment or GTM, even though this definition should be avoided as much as possible.)

---

<div class="post-metadata">

### Author: ![Eduardo\_Braga](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/eduardo_braga/32/110348_2.png) [@Eduardo\_Braga](https://meta.discourse.org/u/Eduardo_Braga)
#### Post date: [January 29, 2020, 8:58pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/23 "2020-01-29T20:58:56Z")

</div>

[https://meta.discourse.org/t/white-blank-advertisement/140098/3?u=eduardo\_braga](https://meta.discourse.org/t/white-blank-advertisement/140098/3)

 ![f6d23d4793c72e3ec881bb91bc944392e70dba64](https://global.discourse-cdn.com/meta/original/3X/c/7/c7e12806f56ef2058e3e02548e529293fd4bc21e.png)

**this solves the problem of the error**

 ![048dd28339b5f74ef6652db6e612b32045e3ccc6](https://global.discourse-cdn.com/meta/original/3X/3/5/35741fb9a1b5d9bd8abcb63e079894e97a25232f.png)

---

<div class="post-metadata">

### Author: ![adrelanos](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/adrelanos/32/121409_2.png) [@adrelanos](https://meta.discourse.org/u/adrelanos)
#### Post date: [June 2, 2020, 4:07pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/24 "2020-06-02T16:07:41Z")

</div>

Could you please add a [Feature-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy)?

This is the one that I am using for more than a year now. (host nginx)

> add\_header Feature-Policy “geolocation ‘none’; midi ‘none’; notifications ‘self’; push ‘none’; sync-xhr ‘none’; microphone ‘none’; camera ‘none’; magnetometer ‘none’; gyroscope ‘none’; speaker ‘none’; vibrate ‘none’; fullscreen ‘none’; payment ‘none’;”;

* * *

Would it make sense to add the following to `Content-Security-Policy` header? This is what I am successfully using (added by host nginx, on top of discourse built-in CSP):

```
default-src 'none'
style-src 'self' domain 'unsafe-inline'
img-src https://*.domain.org data: blob: 'unsafe-inline'
font-src 'self' domain
connect-src 'self' domain
manifest-src 'self' domain

```

---

<div class="post-metadata">

### Author: ![jomaxro](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jomaxro/32/126216_2.png) [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [June 2, 2020, 4:13pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/25 "2020-06-02T16:13:29Z")

</div>

> [@adrelanos](#):
>
> Could you please add a [Feature-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy)?

Given that [the spec is still a draft](https://w3c.github.io/webappsec-feature-policy/#feature-policy-http-header-field), I don’t expect us to implement it at this time. The Mozilla website you listed even says:

> The `Feature-Policy` header is still in an experimental state, and is subject to change at any time. Be wary of this when implementing Feature Policy on your website.

---

<div class="post-metadata">

### Author: ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)
#### Post date: [June 2, 2020, 4:20pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/26 "2020-06-02T16:20:06Z")

</div>

> [@adrelanos](#):
>
> vibrate ‘none’;

`vibrate 'self'` - likes on Android trigger a faint, brief vibration.

---

<div class="post-metadata">

### Author: ![R\_X](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/r_x/32/142155_2.png) [@R\_X](https://meta.discourse.org/u/R_X)
#### Post date: [August 13, 2020, 8:15am UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/29 "2020-08-13T08:15:05Z")

</div>

I just installed discourse 2.6.0.beta1 . Do i need to reconfigure this? Thank you

---

<div class="post-metadata">

### Author: ![jomaxro](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jomaxro/32/126216_2.png) [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [August 13, 2020, 2:58pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/30 "2020-08-13T14:58:15Z")

</div>

You do not, this is on by default. You only need to modify the config if you’re seeing external resources that are being blocked and you want them to run.

---

<div class="post-metadata">

### Author: ![bvdrie72](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/bvdrie72/32/158775_2.png) [@bvdrie72](https://meta.discourse.org/u/bvdrie72)
#### Post date: [September 2, 2020, 5:46pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/31 "2020-09-02T17:46:46Z")

</div>

I am running 2.6.0 beta 2.

I use the following services in the forums:

- Google Tag Manager
- Google Ad Manager
- Google Ad Sense

Currently, I am using report CSP only while I try to resolve all open issues.

Here are my CSP settings:

 ![image](https://global.discourse-cdn.com/meta/original/3X/7/f/7ffb47f6c6b55e641014cee70e2c384e81c38821.png)

With the current settings, I am still receiving LOTS of CSP errors. Some seem like they can be ignored. However this one is boggling me as I have domain declared in the CSP settings.

Am I missing something?

`CSP Violation: 'https://www.googletagmanager.com/gtm.js?id=GTM-T9ZW6PR' `

backtrace:

```plaintext
/var/www/discourse/app/controllers/csp_reports_controller.rb:9:in `create'
actionpack-6.0.3.2/lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
actionpack-6.0.3.2/lib/abstract_controller/base.rb:195:in `process_action'
actionpack-6.0.3.2/lib/action_controller/metal/rendering.rb:30:in `process_action'
actionpack-6.0.3.2/lib/abstract_controller/callbacks.rb:42:in `block in process_action'
activesupport-6.0.3.2/lib/active_support/callbacks.rb:112:in `block in run_callbacks'
/var/www/discourse/app/controllers/application_controller.rb:340:in `block in with_resolved_locale'
i18n-1.8.5/lib/i18n.rb:313:in `with_locale'
/var/www/discourse/app/controllers/application_controller.rb:340:in `with_resolved_locale'
activesupport-6.0.3.2/lib/active_support/callbacks.rb:121:in `block in run_callbacks'
activesupport-6.0.3.2/lib/active_support/callbacks.rb:139:in `run_callbacks'
actionpack-6.0.3.2/lib/abstract_controller/callbacks.rb:41:in `process_action'
actionpack-6.0.3.2/lib/action_controller/metal/rescue.rb:22:in `process_action'
actionpack-6.0.3.2/lib/action_controller/metal/instrumentation.rb:33:in `block in process_action'
activesupport-6.0.3.2/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.3.2/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.3.2/lib/active_support/notifications.rb:180:in `instrument'
actionpack-6.0.3.2/lib/action_controller/metal/instrumentation.rb:32:in `process_action'
actionpack-6.0.3.2/lib/action_controller/metal/params_wrapper.rb:245:in `process_action'
activerecord-6.0.3.2/lib/active_record/railties/controller_runtime.rb:27:in `process_action'
actionpack-6.0.3.2/lib/abstract_controller/base.rb:136:in `process'
actionview-6.0.3.2/lib/action_view/rendering.rb:39:in `process'
rack-mini-profiler-2.0.4/lib/mini_profiler/profiling_methods.rb:78:in `block in profile_method'
actionpack-6.0.3.2/lib/action_controller/metal.rb:190:in `dispatch'
actionpack-6.0.3.2/lib/action_controller/metal.rb:254:in `dispatch'
actionpack-6.0.3.2/lib/action_dispatch/routing/route_set.rb:50:in `dispatch'
actionpack-6.0.3.2/lib/action_dispatch/routing/route_set.rb:33:in `serve'
actionpack-6.0.3.2/lib/action_dispatch/journey/router.rb:49:in `block in serve'
actionpack-6.0.3.2/lib/action_dispatch/journey/router.rb:32:in `each'
actionpack-6.0.3.2/lib/action_dispatch/journey/router.rb:32:in `serve'
actionpack-6.0.3.2/lib/action_dispatch/routing/route_set.rb:834:in `call'
/var/www/discourse/lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
rack-2.2.3/lib/rack/tempfile_reaper.rb:15:in `call'
rack-2.2.3/lib/rack/conditional_get.rb:40:in `call'
rack-2.2.3/lib/rack/head.rb:12:in `call'
/var/www/discourse/lib/content_security_policy/middleware.rb:12:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:336:in `call'
rack-2.2.3/lib/rack/session/abstract/id.rb:266:in `context'
rack-2.2.3/lib/rack/session/abstract/id.rb:260:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/cookies.rb:648:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'
activesupport-6.0.3.2/lib/active_support/callbacks.rb:101:in `run_callbacks'
actionpack-6.0.3.2/lib/action_dispatch/middleware/callbacks.rb:26:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/actionable_exceptions.rb:17:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/debug_exceptions.rb:32:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
logster-2.9.3/lib/logster/middleware/reporter.rb:43:in `call'
railties-6.0.3.2/lib/rails/rack/logger.rb:37:in `call_app'
railties-6.0.3.2/lib/rails/rack/logger.rb:28:in `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:19:in `call'
/var/www/discourse/config/initializers/100-silence_logger.rb:31:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/request_id.rb:27:in `call'
/var/www/discourse/lib/middleware/enforce_hostname.rb:22:in `call'
rack-2.2.3/lib/rack/method_override.rb:24:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/executor.rb:14:in `call'
rack-2.2.3/lib/rack/sendfile.rb:110:in `call'
actionpack-6.0.3.2/lib/action_dispatch/middleware/host_authorization.rb:76:in `call'
rack-mini-profiler-2.0.4/lib/mini_profiler/profiler.rb:200:in `call'
message_bus-3.3.1/lib/message_bus/rack/middleware.rb:61:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:176:in `call'
railties-6.0.3.2/lib/rails/engine.rb:527:in `call'
railties-6.0.3.2/lib/rails/railtie.rb:190:in `public_send'
railties-6.0.3.2/lib/rails/railtie.rb:190:in `method_missing'
rack-2.2.3/lib/rack/urlmap.rb:74:in `block in call'
rack-2.2.3/lib/rack/urlmap.rb:58:in `each'
rack-2.2.3/lib/rack/urlmap.rb:58:in `call'
unicorn-5.6.0/lib/unicorn/http_server.rb:632:in `process_client'
unicorn-5.6.0/lib/unicorn/http_server.rb:728:in `worker_loop'
unicorn-5.6.0/lib/unicorn/http_server.rb:548:in `spawn_missing_workers'
unicorn-5.6.0/lib/unicorn/http_server.rb:144:in `start'
unicorn-5.6.0/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'

```

Env 1:

```plaintext

hostname	forums-web-only
process_id	27127
application_version	f2e14a3946b020ace5a368614f0da198cd17aa32
HTTP_HOST	forums.paddling.com
REQUEST_URI	/csp_reports
REQUEST_METHOD	POST
HTTP_USER_AGENT	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0
HTTP_ACCEPT	*/*
HTTP_X_FORWARDED_FOR	74.76.45.218
HTTP_X_REAL_IP	74.76.45.218
time	1:44 pm

```

Env 2:

```plaintext

hostname	forums-web-only
process_id	27161
application_version	f2e14a3946b020ace5a368614f0da198cd17aa32
HTTP_HOST	forums.paddling.com
REQUEST_URI	/csp_reports
REQUEST_METHOD	POST
HTTP_USER_AGENT	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
HTTP_ACCEPT	*/*
HTTP_X_FORWARDED_FOR	66.58.144.146
HTTP_X_REAL_IP	66.58.144.146
time	1:39 pm

```

Env 3:

```plaintext
hostname	forums-web-only
process_id	27111
application_version	f2e14a3946b020ace5a368614f0da198cd17aa32
HTTP_HOST	forums.paddling.com
REQUEST_URI	/csp_reports
REQUEST_METHOD	POST
HTTP_USER_AGENT	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
HTTP_ACCEPT	*/*
HTTP_REFERER	https://forums.paddling.com/t/need-advice-loading-a-kayak-onto-j-rac/60058
HTTP_X_FORWARDED_FOR	174.83.24.11
HTTP_X_REAL_IP	174.83.24.11
time	12:16 pm

```

---

<div class="post-metadata">

### Author: ![pmusaraj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pmusaraj/32/119489_2.png) [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [September 2, 2020, 6:19pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/32 "2020-09-02T18:19:27Z")

</div>

There are lots and lots of false positives in CSP reporting. See my [reply above](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/3) for more details.

You don’t need most of the rules you have set in your screenshot, just `https:` and `unsafe-inline` are enough, they allow all scripts starting with https and all inline scripts. Try cleaning up your CSP sources setting and enabling CSP (without reporting), it should work.

---

<div class="post-metadata">

### Author: ![koen360](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/koen360/32/194302_2.png) [@koen360](https://meta.discourse.org/u/koen360)
#### Post date: [January 2, 2021, 9:53pm UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/33 "2021-01-02T21:53:43Z")

</div>

Hi just wondering, the [Content-Security-Policy: frame-ancestors ‘none’](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive is one that “will be included in future updates” as mentioned by the OP?

Is it possible to add that directive somehow or should I just wait and not worry about it. Was just doing a hardening exercise and this was the only open item / recommendation by that online security tool. Gives me a lot of confidence in the platform actually, great job guys!

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [January 3, 2021, 6:39am UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/34 "2021-01-03T06:39:49Z")

</div>

I’m not sure – what do you think @xrav3nz?

---

<div class="post-metadata">

### Author: ![xrav3nz](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/xrav3nz/32/76894_2.png) [@xrav3nz](https://meta.discourse.org/u/xrav3nz)
#### Post date: [January 4, 2021, 4:20am UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/35 "2021-01-04T04:20:28Z")

</div>

> [@koen360](#):
>
> Is it possible to add that directive somehow or should I just wait and not worry about it.

I’d say don’t worry about it for now.

`frame-ancestors` is similar to [`X-Frame-Options` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options) which Discourse/Rails already enforces. The header is currently set to `sameorigin` – roughly the same as the CSP directive’s `self` option.

IMO we won’t gain much from implementing `frame-ancestors` right now, unless we need to support whitelisting specific domains other than `self`.

---

<div class="post-metadata">

### Author: ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [January 4, 2021, 4:57am UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/36 "2021-01-04T04:57:44Z")

</div>

> [@xrav3nz](#):
>
> I’d say don’t worry about it for now.
> 
> `frame-ancestors` is similar to [`X-Frame-Options` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options) which Discourse/Rails already enforces. The header is currently set to `sameorigin` – roughly the same as the CSP directive’s `self` option.

I agree with this.

Chasing every possible vulnerability scanner “issue” can end up breaking things which are important, for a very little risk-benefit ratio.

There are a lot of “vulnerabilities in theory” which are rarely exploited or can only be exploited under a very specific scenario. These types of potential vulnerabilities have never been exploited on a Discourse site, to my knowledge; and I would advise against “fixing” things which are “in theory’” a vulnerability that have not resulted in a breach of any consequence.

That’s my 2 cents as a many decades long cybersecurity professional. I am happy to discuss the basics of cybersecurity risk management if anyone is interested.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [March 23, 2021, 12:11am UTC](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/37 "2021-03-23T00:11:15Z")

</div>

> [@koen360](#):
>
> Hi just wondering, the [Content-Security-Policy: frame-ancestors ‘none’](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive is one that “will be included in future updates” as mentioned by the OP?

We just landed support for CSP `frame-ancestors` directive. It’s disabled by default for now behind the `content security policy frame ancestors` site setting. You can add domains to the list using via `/admin/customize/embedding` as always.

This directive will be enabled by default in the next release cycle.

[Next page](https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243.md?page=2)