Reducing POST Requests: CSP Violations

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.

• If using syslog:
  • For Acquia Cloud Classic or Acquia Cloud Next applications: Download drupal-watchdog.log file(s) via Cloud UI and unzip / search for log messages containing /report-csp-violation
  • For Acquia Cloud Classic, you could also SSH to the server, navigate to the logs directory, and run a command like this: zgrep "csp-violation" drupal-watchdog.log-20230120.gz
• If using dblog: Check "Recent log messages" in Drupal

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

Notes:

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