W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2016

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

From: Scott Helme <scotthelme@hotmail.com>
Date: Thu, 17 Mar 2016 10:11:49 +0000
Message-ID: <BLU436-SMTP1400997F4D8F0837812865BD98B0@phx.gbl>
To: public-webappsec@w3.org
At first glance it seems like a 'require-sri' keyword that you could
drop into default/script/style-src would be more straightforward.

If 'require-sri' became a new directive would it be an on/off setting
like 'upgrade-insecure-requests' or could you configure which resource
types it applies to? Would you need to?


Scott Helme / Information Security Consultant
PGP Key <https://scotthelme.co.uk/contact/>


Twitter <https://twitter.com/Scott_Helme>Facebook
<https://github.com/ScottHelme/>Skype <scott.helme87>

On 17/03/2016 09:55, Mike West wrote:
> I'm fine with a `require-sri` source expression that could be added to
> `script-src`, or a `require-sri` directive that stands on its own.
> I lean towards the latter because it feels a little strange to treat
> this kind of requirement as a "source", and because having a separate
> directive for this policy change probably fits better with CSP's
> extensibility model (and is easily defined in a separate document from
> CSP itself). If someone feels strongly about using the former I'd
> probably accept a PR, though. :)
> -mike
> On Wed, Mar 16, 2016 at 7:11 PM, Scott Helme <scotthelme@hotmail.com
> <mailto:scotthelme@hotmail.com>> wrote:
>     I agree, I'd love to see some traction with this.
>     Angular will soon be providing the appropriate script tags with
>     integrity values for each release:
>     https://github.com/angular/angular.js/issues/13968#issuecomment-181633726
>     This makes deploying SRI a matter of copy and paste.
>     SRI is much easier to deploy than CSP and only requires
>     maintenance when you change the script/style tag itself, CSP
>     requires ongoing knowledge and maintenance.
>     I think adoption of SRI will likely eclipse CSP relatively soon,
>     I'm betting with you, not against!
>     Regards,
>     Scott Helme / Information Security Consultant
>     PGP Key <https://scotthelme.co.uk/contact/>
>     https://scotthelme.co.uk
>     https://report-uri.io
>     https://securityheaders.io
>     https://scotthel.me
>     Twitter <https://twitter.com/Scott_Helme>Facebook
>     <https://www.facebook.com/scott.helme>GooglePlus
>     <https://plus.google.com/+ScottHelme/posts>YouTube
>     <https://www.youtube.com/user/ScottHelme>LinkedIn
>     <https://uk.linkedin.com/in/scotthelme>GitHub
>     <https://github.com/ScottHelme/>Skype <http://scott.helme87>
>     On 16/03/2016 17:18, Neil Matatall 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> <mailto:patrick.toomey@github.com> wrote:
>>>     On Wed, Feb 10, 2016 at 7:47 AM Frederik Braun <fbraun@mozilla.com> <mailto: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 Thursday, 17 March 2016 10:21:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:55 UTC