Script-src-elem being reported although script-src is defined

Question

Related: Why is script-src-elem not using values from script-src as a fallback?

I am seeing a low of CSP reports where e.g. https://track.adform.net/serving/scripts/trackpoint/async/ is blocked due to the effective directive script-src-elem. As you can see in the policy below I am not defining script-src-elem but expect it to fall back to script-src or even default-src. That is my in my debugging this policy looks the way it does.

I have not been able to reproduce the report myself.

Full report:

{
    "csp-report": {
        "document-uri": "https://www.example.com/some/uri",
        "effective-directive": "script-src-elem",
        "original-policy": "default-src 'self' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;script-src 'self' 'unsafe-inline' 'unsafe-eval' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;style-src 'self' 'unsafe-inline' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;img-src 'self' * data:;report-uri https://example.report-uri.com/r/d/csp/reportOnly",
        "blocked-uri": "https://track.adform.net/serving/scripts/trackpoint/async/"
    }
}

I am only seeing it in the chrome browser on primarily Windows. There is a bug [1] report in the Chromium tracker but that was closed off without further investigation and seem to affect something else.

Is there something wrong with my policy or perhaps a bug should be opened in the tracker again?

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=880816

Answer 1

Script-src-elem being reported although script-src is defined

• Chrome acts strongly with comply to CSP3 spec, it reports the violated-directive as effective-directive. Chrome sends effective-directive where violation should occurred if such directive will be presented in the policy.

• Firefox despite CSP3 spec does send a really violated-directive as it appears in the policy. This will contain the default-src directive in the case of violations caused by falling back to the default sources when enforcing a directive.

• The browser console always displays the actually violated directive as it present in the policy.

Therefore in case of policy:

default-src 'none'

• Chrome sends a script-src-elem for <script> and <script src=>, and sends a script-src-attr for inline event handlers and javascript:-navigation, except one bug (this bug does not touch your CSP since inline scripts are allowed).

• Forefox sends a default-src in the violation report.

Whose behaviour is more useful is an open question, but I prefer Firefoxes one.
Because Chrome can make crazy anyone who looking for the cause of violations in the case of a long chain of fallback directives, such as in the case of the Worker, especially when some browsers skip some fallback directives in this chain.

So here we don't even need to "go to the doctor", in your case the script-src is really used for any scripts.

The right question is why https://track.adform.net/serving/scripts/trackpoint/async/ is occasionally blocked in the script-src directive despite the *.adform.net source is specified in it.

Since the situation cannot be reproduced, the only way is analyze the statistics - user agents and IPs.

If IP belongs to public hosting, you can just ignore such violations - it's a bots.

If is blocking the only one URL https://track.adform.net/serving/scripts/trackpoint/async/, it could be some browser "privacy" extensions like mentioned here, because this URL is a tracker.

Is the browser.sentry-cdn.com source mean you use a sentry? Does sentry shows the CSP errors? It should catch those, because CSP violations has built-in javascript errors handlers via SecurityPolicyViolationEvent.

PS: I have met only one odd "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36" which blocked all HTTPS: sources. As as it was seen from the original-policy, this user agent just removes all https:// from the policy.

Is there something wrong with my policy or perhaps a bug should be opened in the tracker again?

I do not see anything wrong in your CSP. Anyway it should NOT lock https://track.adform.net/serving/scripts/trackpoint/async/.
IMHO to open a bug it need collect some specifics.