Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on Why does Firefox block based on a restrictive default-src directive, when more specific, more permissive *-src exist?
Parent
Why does Firefox block based on a restrictive default-src directive, when more specific, more permissive *-src exist?
I am working on a website which unfortunately uses a mix of linked and inline CSS and Javascript (and, even more unfortunately, I can't do a lot about the use of inline CSS and Javascript), and am trying to set up an appropriate Content-Security-Policy for it.
When I serve the content (over proper HTTPS with a CA-signed certificate) with a CSP that doesn't include any default-src directive, things work as I expect. For example, if the HTTP response contains the two HTTP headers
Content-Security-Policy: style-src 'self' 'unsafe-inline' https://fonts.googleapis.com/;
Content-Security-Policy: font-src 'self' https://fonts.gstatic.com/;
then Google-hosted fonts are loaded; if I remove the https://fonts.gstatic.com/ entry from font-src but leave the font-src directive itself in place, then the browser reports that they were blocked based on font-src. This is exactly what I expect to happen.
However, if I also add a third HTTP header
Content-Security-Policy: default-src 'self';
then I get a whole bunch of errors, including ones where the reference points at the beginning of an inline <style> element, even though I'm still serving the same style-src directive as above including the 'unsafe-inline' in its own CSP HTTP header.
MDN says that (my emphasis):
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives. For each of the following directives that are absent, the user agent looks for the default-src directive and uses this value for it:
style-src is one of the directives thus listed, and 'self' is one of the valid values for default-src.
I would expect the more specific (and in this case, more permissive) style-src to take precedence over the more restrictive, fallback default-src, but that doesn't seem to be happening. Rather, it seems that the default-src directive is being used instead of (or possibly as further restricting) the more specific style-src directive.
Although Firefox doesn't currently support the corresponding *-src-attr and *-src-elem directives, I tried adding script-src-attr, script-src-elem, style-src-attr and style-src-elem anyway with the same value as script-src and style-src respectively just to see if it would make any difference. The only observable difference was the browser complaining about the four unsupported CSP directives.
What am I missing? Is the CSP default-src directive useless for my use case, and I need to list all CSP directives explicitly to get the effect I am after, namely providing a highly restrictive policy for everything that doesn't actually need to be more permissive?
Post
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| Canina | (no comment) | Nov 6, 2021 at 11:32 |
Each header is checked independently
Having multiple Content Security Policy headers can only make it more restrictive
I assume that each Content-Security-Policy: line you have is a separate CSP header. If you send each separately, then a source will be checked on each CSP separately.
For example, the way your inline style is checked is we first check the first policy.
Content-Security-Policy: style-src 'self' 'unsafe-inline' https://fonts.googleapis.com/;
All good here, we have 'unsafe-inline'. The problem comes at the last header.
Content-Security-Policy: default-src 'self';
This header doesn't have style-src, so it checks default-src which only allows 'self', and so it blocks it, throwing the error that you got.
Solution: Put all the policies in one header
Content-Security-Policy:
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com/;
font-src 'self' https://fonts.gstatic.com/;
default-src 'self';
W3C Specification
The level 3 specification states
When the user agent receives a Content-Security-Policy header field, it MUST parse and enforce each serialized CSP it contains as described in § 4.1 Integration with Fetch, § 4.2 Integration with HTML.
The important part of this is that parsing results in a new, independent policy being created for each header. Enforcing just means inserting that new policy into the global CSP list.
Digging a bit deeper, we find the algorithm used to determine if a request should be blocked: Should request be blocked by Content Security Policy?
- Let CSP list be request’s policy container's CSP list.
- Let result be "Allowed".
- For each policy in CSP list:
- If policy’s disposition is "report", then skip to the next policy.
- Let violates be the result of executing § 6.6.2.1 Does request violate policy? on request and policy.
- If violates is not "Does Not Violate", then:
- Execute § 5.3 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.
- Set result to "Blocked".
- Return result.
As you can see, each policy is evaluated independently, and a request must pass all of them. Since each header creates a new policy, this means that sending multiple headers will only further restrict the requests that pass.
2 comment threads