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

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> 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
> [image: Twitter] <https://twitter.com/Scott_Helme>[image: Facebook]
> <https://www.facebook.com/scott.helme>[image: GooglePlus]
> <https://plus.google.com/+ScottHelme/posts>[image: YouTube]
> <https://www.youtube.com/user/ScottHelme>[image: LinkedIn]
> <https://uk.linkedin.com/in/scotthelme>[image: GitHub]
> <https://github.com/ScottHelme/>[image: 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 noopenerhttps://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> <patrick.toomey@github.com> wrote:
>
> On Wed, Feb 10, 2016 at 7:47 AM Frederik Braun <fbraun@mozilla.com> <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.
>
>
>