Hello,

Last week (yesterday), I changed my server configuration to add a CSP header. Now I switched to using this module instead with the attached configuration.

And the patches on Blazy and Matomo from comments on #3099548: Implement Policy Alter event in other modules.

I cleared Varnish and Nginx (SSL reverse-proxy) cache. And I see the expected header value.

Problem: when rescanning my website (https://observatory.mozilla.org/analyze/florent-torregrosa.fr), it seems not to detect CSP header correctly.

As an anonymous, I have the following header value:

default-src 'none'; connect-src 'self' https:; font-src 'self' https:; img-src 'self' https: data:; script-src 'self' https: 'unsafe-inline'; style-src 'self' https:; base-uri 'self' https:; frame-ancestors 'self' https:

I expected the following rules to be OK:

  • Blocks inline styles by not allowing 'unsafe-inline' inside style-src
  • Clickjacking protection, using frame-ancestors (it was with server configuration)
  • Restricts use of the tag by using base-uri 'none', base-uri 'self', or specific origins (it was with server configuration)

Thanks for any help.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Grimreaper created an issue. See original summary.

gapple’s picture

I'm not sure if Observatory is warning about style-src https:, but only mentioning 'unsafe-inline' in the details analysis message. The Google CSP validator accepts style-src 'self' https: as fine (https://csp-evaluator.withgoogle.com/?csp=https://florent-torregrosa.fr)

Defining particular external hosts which are allowed is preferable to allowing all external hosts with https: - it's not difficult for a malicious user to host their desired JS / CSS file on a domain with HTTPS. The CSP module will automatically add any external hosts defined in library definitions, so it's only necessary to add additional script or style domains if they're added through an alternate method than the asset library system.

CSP Summary
Detailed CSP Info

Grimreaper’s picture

Thanks a lot for your reply.

Having both scans from Mozilla and Google is useful.

I will make some checks and keep this issue updated.

I think it is because when I first tried to resolve Mozilla analysis using server configuration, I typed

https

and not

https:

like verified by the CSP module when I configured it. So the rule was wrong and Mozilla did not warn about https, but now warns about https:

I will check that.

This header is a little bit new for me so I am not aware of the best practices. So thanks a lot again for your help.

Grimreaper’s picture

Status: Active » Fixed

You were right! It was because of https: too wide.

After config and patches on other contrib modules rework. It is ok.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.