Allow nonce-source to be used in more directives.

[ScottHelme]

I recently deployed nonce support on my site and it makes deploying a strong CSP considerably easier. A lot easier than I thought it was going to be now I've actually done it. One of the other aspects I liked was that my ridiculously huge script-src and style-src directives were cut down by more than 90%.

This got me thinking it'd be nice to simplify the rest of my policy and use nonces in other elements on the page. Things like img-src, child-src, frame-src and even the default-src perhaps?

Could we extend the nonce-source to be used more widely?

[ScottHelme]

Checking if this is a sane proposal: @mikewest @marumari @ptoomey3 @jonathanKingston @oreoshake

[shekyan]

I am not in the list of selected people, so sorry for jumping in. Is changing from external resources whitelisted in source-list to inline scripts whitelisted by nonce made your policy shorter?

Can you give an example of how do you see a nonce used with, say image?

[ScottHelme]

Hi @shekyan, no problem, I was just dropping some names in there of people that jumped to mind :-)

I think you may have misunderstood the change I've made, I've not moved to inline scripts, I've changed from this:

Content-Security-Policy: script-src example.com cdn.com othersite.com mycdn.com whatever.com
<script src="example.com/script.js"></script>

To this:

Content-Security-Policy: script-src 'nonce-abc123'
<script src="example.com/script.js" nonce="abc123"></script>

This way I don't need to whitelist the many hosts that I load various assets from nor do I need to maintain that list going forwards.

For images, or other resource types, I was thinking of the exact same approach, going from this:

Content-Security-Policy: img-src example.com cdn.com othersite.com mycdn.com whatever.com
<img src="example.com/kitten.jpg"/>

To this:

Content-Security-Policy: img-src 'nonce-abc123'
<img src="example.com/kitten.jpg" nonce="abc123"/>  

It seems like the benefit of the nonce approach can be easily passed on to other elements on the page, further reducing the burden of CSP.

<iframe src="example.com" nonce="abc123"></iframe>
<link rel="stylesheet" href="font.example.com" nonce="abc123">
etc...

[ScottHelme]

For reference, you can see the policy I'm currently testing and the changes I'm making here:

https://securityheaders.io/?q=https%3A%2F%2Fscotthelme.co.uk%2F&followRedirects=on

I have my live policy in the CSP header and I'm testing nonces in the CSPRO header.

[ptoomey3]

Seems sensible to me. I don't see any real downsides, and consistency is a nice usability win. I always have to double check what sources default-src applies to, but might it make sense to apply it for all *-src directives in the name of consistency?

[ptoomey3]

and even the default-src perhaps?

I see you covered this already 😀...not.the first time writing a reply 30 minutes after reading a comment has bitten me. My short-term memory is, as they say, not so good.

[shekyan]

I keep forgetting that nonces are also applicable to external resources :( Makes sense to me to expand to other resources.
As about default-src, nonce-source keyword can part of it's source-list today, so with every new directive supporting nonces default-src will automatically cover it.

[mikewest]

I think we'll run into the same problem here that we have with 'unsafe-hashed-attributes', in that there doesn't seem to be a way to construct the syntax such that a site's policy remains backwards compatible with browsers that don't support the new thing. I'm not sure how catastrophic that is, but it's something to consider when adding new functionality.

[ScottHelme]

Wouldn't backwards compatibility work in the same way that it does for script-src and style-src? The following policy should be CSP 1, 2 and 3 compliant, no?

Content-Security-Policy: img-src example.com 'nonce-abc123'
<img src="example.com/kitten.jpg" nonce="abc123"/>

Perhaps I've missed something, in which case it'd be great if you could explain! :)

[mikewest]

Wouldn't backwards compatibility work in the same way that it does for script-src and style-src? The following policy should be CSP 1, 2 and 3 compliant, no?

Yes, but not while at the same time "simplif[ing] the rest of [your] policy" as you suggested at the top. That is, it would work fine as a purely additive mechanism in addition to your existing whitelist, but then there's no advantage to adding it. :)

shrug If folks really want to use nonces for other kinds of resources, I don't have a fundamental problem with adding them to the framework. There's a lot of wiring things together that we'd need to do in HTML to make this work (to say nothing of the same that would need to be done in actual implementation code), so I'm not dying to add it. It seems like a lot of work for me, for very little advantage for you. :) But if it's useful, we can make it work.

[ScottHelme]

Ok I see. For the present day, yes, I agree. However, I do see a point in the future where we have widespread CSP 3 support. At that time I think it'd be nice if we could use nonces across the board instead of it being limited to styles and scripts with a whitelist for everything else still. There is a technical cost to implementing nonces so it'd be great if they were a replacement for the cost of implementing and maintaining the whitelist instead of in addition to it. My perfect scenario would be:

Content-Security-Policy default-src 'nonce-abc123'

[aidantwoods]

@mikewest

That is, it would work fine as a purely additive mechanism in addition to your existing whitelist, but then there's no advantage to adding it. :)

Would the approach used in 'strict-dynamic' not be a good reference here?

If present in a script-src or default-src directive, it has two main effects:

1. host-source and scheme-source expressions, as well as the "'unsafe-inline'" and "'self' keyword-sources will be ignored when loading script.

hash-source and nonce-source expressions will be honored.
...

Using @ScottHelme's example, perhaps the following

Content-Security-Policy: img-src example.com 'nonce-abc123' 'strict-dynamic'
<img src="example.com/kitten.jpg" nonce="abc123"/>

Would look like

Content-Security-Policy: img-src example.com

to CSP 1 and 2 browsers

and

Content-Security-Policy: img-src 'nonce-abc123' 'strict-dynamic'

to CSP 3 browsers.

Either way, this would still load

<img src="example.com/kitten.jpg" nonce="abc123"/>

[frederikbosch]

This directive could also enable inline style in a SVG that is referenced.

page.html

Content-Security-Policy: img-src example.com 'nonce-abc123'
<img src="example.com/kitten.svg" nonce="abc123"/>

kitten.svg

<svg><style>.class{display:none;}</style></svg>

I am not aware of any solution for inline style in a referenced SVG within the current framework. Or am I missing something?

[dveditz]

I'm not sure why a document's CSP applies to the internals of a completely separate svg image load. in-line SVG, sure -- we should block the inline style. But the external SVG image is a completely separate document (which could have its down CSP I suppose).

[frederikbosch]

@dveditz You are right. But also consider this. The web is increasingly using SVGs for a variety of solutions. If you create SVGs using apps like Illustrator, inline style is quite common I would say. Since SVG does not have a <meta> tag like HTML, there is no possibility to create a safe SVG-with-inline-style file without sending the Content-Security-Policy header. The header solution is quite a complicated solution with possibly quite some scripting involved. HTML documents are usually rendered by the scripting language already, making it a little more easy to add the header and inject nonce on the specific tags. That is not so easy for SVG, because it usually never reaches the scripting language in the first place (send directly by the webserver).

So maybe my proposed solution is in the wrong direction, but at least one can say it is really difficult for external SVGs to have inline style and be compliant with a Content Security Policy.

[eligrey]

@frederikbosch I think you can apply CSP to a SVG document with a <foreignObject> containing <html:head><html:meta name="Content-Security-Policy" content="…"></html:meta></html:head>.