These past days I have been working on implementing CSP headers for a few legacy sites. While 📌 [D7] Convert drupalSettings from JavaScript to JSON, to allow for CSP in the future RTBC is a good idea, it solves only one minor problem for adopting CSP and I think there is a much more direct / feasible route which also enables more of contrib to work:
- Authenticate scripts using nonces as implemented in the d7csp module. This already solves the problem with inline scripts including the Drupal settings.
- Apply the patch from ✨ Forward CSP nonces when inserting JS from AJAX requests Active to also forward the nonce to AJAX loaded JS
- Use seckit’s config or a hooks as provided by d7csp to declare the rest of the resources needed.
- Catch any stray inline styles or JavaScript that’s embedded bypassing
drupal_add_js().
Overall I think using nonces are the easiest way to introduce CSP to Drupal 7 sites. It works without changing Drupal settings. Apart from the minor change to misc/ajax.js anything else can be handled in contrib.
torotil → created an issue. See original summary → .
For easier patching I’m also attaching a diff here in addition to the issue fork.
While it’s technically true that the README mentioned polyfill.io as as an example, it’s a bit strange for me to consider that a security issue.
However I’ve removed it from the README and tagged a new 7.x-1.3 (bugfix) release for this. I also removed the same sentence in the project description.
Hi! Thanks for taking the time to merge the patch. I hope it is still of use to some even though the Drupal 7 end-of-life is now only months away. At least it’s a nice gesture.
Issues like this are the reason we’ve decided to move away from Drupal as a company years ago. It took 5 years for a maintainer of a module used on 250k+ sites to review a rather fundamental issue even though it has lead to workarounds in other popular modules (file_entity/media) already.
I don’t think this will lead to a change in Drupal 7 at this point, but actually the reason cited here is wrong. The HTTP specs say:
If no Accept-Encoding header field is in the request, any content coding is considered acceptable by the user agent.
— https://www.rfc-editor.org/rfc/rfc9110.html#section-12.5.3-10.1
Users can work around this by either explicitly specifying Accept-Encoding: identity or by handling the Content-Encoding header as is shown here: https://drupal.stackexchange.com/a/136774
Here is a patch for 1.19.5 that also includes the changelog (which is now in changelog.md).