A best practice for Drupal sites is to add and manage a content security policy (CSP) http header, to mitigate risks such as cross-site scripting and data injection attacks. While you can add or modify http headers using a CDN rule, the best place to add the header is within your Drupal application, which works whether or not you have a CDN in front of your domain. Within the Drupal community, the common implementation method is to install the Security Kit contrib module, commonly referred to by its machine name, 'seckit.' Seckit includes a UI for managing a CSP, but there are other contrib modules/methods, as well.
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.
What can your team do to fix a high count of /report-csp-violation POST requests? Of course, you could disable the CSP ' or maybe turn off logging temporarily ' but neither would be a best practice solution for the long term.
Steps you can take to find and fix /report-csp-violation requests
The goal is to find the URI(s) and either add them to the CSP or remove the code or content that's requesting the blocked URI.
1. Check logs for instances of '/report-csp-violation' and find the blocked URIs. You can use syslog or dblog for logging â but see the first item in Notes below.
Note that if you are using something other than seckit to manage your CSP and log violations (or if you change the post request path in seckit), the log message / request path might be different.
2. Review the "Blocked URI" values and determine if they should be allowed or not.
3. Either add these to your content security policy to allow them, or if they should not be allowed, find and remove the code or content that's calling these URIs
4. Periodically monitor the logs and address any other/new violations
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.
Views/Visits/drupal requests: Reducing /report-csp-violation POST requests helps to reduce utilization on the Cloud platform.
Modules referenced:
Core modules: syslog and dblog
Contrib module: seckit: https://www.drupal.org/project/seckit
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Fri Sep 12 2025 08:52:30 GMT+0000 (Coordinated Universal Time)