Re: [CSP] "sri" source expression to enforce SRI

Another option to support the asset type granularity would be to make
a `require-sri` source expression that can be added to script-src,
style-src, img-src, media-src, and unicorn-src.

On Wed, Mar 16, 2016 at 7:18 AM, Neil Matatall <oreoshake@github.com> wrote:
> What can we do to get this moving? No matter the form, I don't think
> there's any disagreement about whether or not this is valuable. We're
> starting to see a proliferation of SRI attributes included in example
> snippets for 3rd party assets. It's my gut instinct* that SRI has the
> possibility of eclipsing CSP in terms of adoption, but that's a
> different topic. It sounds like CSP bloat and SRI changes are the
> biggest hurdles. Something that may alleviate both concerns:
>
>   block-non-sri-resources: stylesheets, scripts(, images, videos, unicorns)
>
> I would still love to see this as a part of CSP, especially if we're
> talking about adding something related to noopener
> https://twitter.com/mikewest/status/710025892970504193. Maybe this
> separate header value can also work as a directive, just remove [:,]
>
> * I'll take bets
>
> On Tue, Feb 16, 2016 at 5:44 AM, Patrick Toomey
> <patrick.toomey@github.com> wrote:
>> On Wed, Feb 10, 2016 at 7:47 AM Frederik Braun <fbraun@mozilla.com> wrote:
>>>
>>> On 09.02.2016 19:35, Craig Francis wrote:
>>> > I'm forgetting the discussion a bit, but CSP already gives us:
>>> >
>>> > block-all-mixed-content
>>> > upgrade-insecure-requests
>>> >
>>> > Maybe we could keep it as just one directive:
>>> >
>>> > block-non-sri-resources
>>> >
>>> > Or am I missing the more advanced cases like saying SRI is required for
>>> > all JavaScript files, but not on CSS (doubt that is useful, as you might
>>> > as well do both)... or maybe in the future SRI could be added to images,
>>> > video, etc?
>>>
>>> We'd need to think about compatibility assuming SRI will expand to other
>>> tags.
>>>
>>> I would be surprised if nobody wanted a report-mode and a block-mode and
>>> a way to specify which subresources/elements should be subject to the
>>> policy. (The list of elements could be abbreviated with a short-hand
>>> form, e.g., "sri-v1" meaning scripts & styles.)
>>>
>>> I guess this level of complexity (and Mark Nottingham's comment about
>>> HPACK and entropy) warrants its own header?
>>>
>>
>> I'm curious where the line should be drawn between extending CSP and adding
>> a new header? Not having been involved with CSP from day one, maybe this has
>> already been discussed. But, I feel like CSP is a natural place to
>> centralize on browser based security policies (like x-frame-options
>> migrating to frame-ancestors). Adding a new header for each and every new
>> good idea for browser security doesn't seem to scale. As has been mentioned
>> in this thread prior, it feels like we are starting to bump up against
>> practical size consideration issues. Whether the CSP header itself grows too
>> large or we end up adding 50 headers to each HTTP response, there is an
>> issue of bloat. It would be a shame to place some artificial cap on good
>> ideas based on concerns for adding too many new headers and/or stretching
>> the size of the CSP header. I personally feel like moving toward a
>> centralized policy/manifest/resource sounds like the best way to handle
>> this, but I think most of that discussion is best had over in the "header
>> size and policy delivery" thread. I just wanted to bring it up here since I
>> think the "where do we put it" discussion should be deferred until later,
>> since it seems like this is a general concern for almost anything new that
>> is proposed.

Received on Wednesday, 16 March 2016 18:31:20 UTC