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?
Post
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?
2 comment threads