https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

"Content Security Policy (CSP) is a feature that helps to prevent or minimize the risk of certain types of security threats. It consists of a series of instructions from a website to a browser, which instruct the browser to place restrictions on the things that the code comprising the site is allowed to do.

The primary use case for CSP is to control which resources, in particular 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 is able to inject malicious code into the victim's site."

There is a Modern Drupal module for this. But, I don't recall seeing anything for Drupal 7 or Backdrop CMS. Has anyone done any work on this? How have you handled it?

https://www.drupal.org/project/csp

Comments

These 2 articles provide some additional information (there is more in the articles) that may be useful for others regarding the use of the seckit module for Drupal and presumably also for Backdrop:

https://acquia.my.site.com/s/article/Why-does-my-site-receive-lots-of-requests-to-report-csp-violation

Normally, a site admin that uses this module also knows that they need to continuously monitor and fix the "Violation" reports that are being sent in automatically (by web browsers being used by site visitors) via the /report-csp-violation URL which causes the seckit module to log each report via Drupal's watchdog system.

 

Ideally, if a site builder is interested in implementing Content-Security-Policy (CSP) directives, they would:

(A) monitor these warnings being reported
... and (B) fix anything that needs to be fixed on the site.

https://dev.acquia.com/blog/reducing-post-requests-report-csp-violation

The “managing” part should not be overlooked here: A typical setup using seckit will log instances of blocked requests to external sites or services that are not included in your CSP. Seckit creates POST requests that show up in logs as “/report-csp-violation” referencing the blocked URI.

If your dev team doesn’t monitor and address these, (a) there may be cases of desired requests being blocked, so your application doesn’t work as expected, and/or (b) there may be a very high count of POST requests, increasing utilization and possibly even impacting performance.

 

syslog vs. dblog: Enabling syslog writes log data to files (which is ideal, and helps our Support team when troubleshooting issues for your application), while the dblog module writes to the database (which can have a performance impact). For production sites, we recommend uninstalling dblog and installing syslog. If you want to use dblog temporarily, remember to uninstall it when finished.