Re: Making it easier to deploy CSP.

On Wed, Feb 17, 2016 at 2:12 AM, Artur Janc <aaj@google.com> wrote:

> On Mon, Feb 15, 2016 at 12:55 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>
>> The thing I'm trying to wrap my head around is how this fits with the
>> general CSP design pattern.  How does adding this directive narrow the
>> set of things that are permitted?  It actually appears to do the
>> opposite.  The purpose being to give dynamically inserted scripts an
>> exemption.
>>
>
> In a way, the directive would indeed expand the set of scripts which can
> be loaded -- because scripts added dynamically to the page by previously
> trusted scripts wouldn't be be subject to the script-src whitelist. At the
> same time, point #2 in Mike's original description proposes ignoring the
> whitelist altogether in the presence of unsafe-dynamic. This, in turn,
> narrows down which scripts can be loaded by the page so that *only* those
> with a nonce/hash, and their descendants, would be allowed to load.
>

Jumping in on this small point: In general, CSP enables pages to opt-into
stricter rules than the platform defaults. That is:

The internets say "Yeah, sure, you can load script X! No worries!" A CSP
whitelist says "No way, script X is totally out of bounds." The
'unsafe-dynamic' keyword we're discussing says "No way, script X is out of
bounds, unless it's inserted in this particular way." This is basically the
same as every other keyword. Take `unsafe-eval`, for instance: it loosens
the default meaning of `script-src`, but only up to the point that it
matches the platform default.

At worst, CSP is exactly the same as the platform default (e.g. `script-src
* blob: 'unsafe-inline' 'unsafe-eval'`). Even in that case, the page can't
do anything it couldn't have done without CSP. That's what I mean when I
talk about CSP as being strictly negative. Carveouts within the negativity
which enhance deployability seem in line with that general philosophy.

-mike