Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs

Dashboard
Notifications
Mark all as read
Q&A

Why does Firefox block based on a restrictive default-src directive, when more specific, more permissive *-src exist?

+8
−0

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?

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

2 comment threads

Stylesheet being loaded perhaps referring to a resource at fonts.gstatic.com? (4 comments)
Sending multiple headers won't work (4 comments)

1 answer

+5
−0

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?

  1. Let CSP list be request’s policy container's CSP list.
  2. Let result be "Allowed".
  3. For each policy in CSP list:
    1. If policy’s disposition is "report", then skip to the next policy.
    2. Let violates be the result of executing § 6.6.2.1 Does request violate policy? on request and policy.
    3. If violates is not "Does Not Violate", then:
      1. 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.
      2. Set result to "Blocked".
  4. 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.

Why does this post require moderator attention?
You might want to add some details to your flag.

2 comment threads

For completeness, include the solution (2 comments)
"I assume that each Content-Security-Policy: line you have is a separate CSP header." (1 comment)

Sign up to answer this question »