Add Integrity-Policy for scripts

[yoavweiss]

As discussed, this is replacing #129

It is defining two new headers: Integrity-Policy and Integrity-Policy-Report-Only that would enable developers to enforce integrity on scripts (in the immediate) and on more request destinations in the future.

Integrity-Policy header

Subresource-Integrity (SRI) enables developers to make sure the assets they intend to load are indeed the assets they are loading. But there's no current way for developers to be sure that all of their scripts are validated using SRI.

The Integrity-Policy header gives developers the ability to assert that every resource of a given type needs to be integrity-checked. If a resource of that type is attempted to be loaded without integrity metadata, that attempt will fail and trigger a violation report.

The Integrity-Policy header is a structured field Dictionary, where every member value is an inner list of tokens.
Possible keys are: blocked-destinations

Example usage

A developer that wants to validate that all of their script resources have integrity checks will be able to add a header similar to:

Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)

From that point, any external script that is fetched without a valid integrity attribute (that is, one that translates into non-empty integrity metadata) or with a "no-cors" request mode, will not be loaded.
It will also trigger a violation report.

The header also has a sources key. It's only possible value (as well as its default value) is "inline". It's presence would enable future-compatible additions of other integrity sources, such as headers.

---

Preview | Diff

[yoavweiss]

@mozfreddyb - this is still missing the reporting parts, but I'd appreciate your feedback on the overall direction.

[mozfreddyb]

Great start, thanks for kicking this off.

[mozfreddyb]

I have yet to look at the reporting bits, but looks good otherwise.

@annevk: Can you review the integration bits (HTML & fetch) or defer to someone who can?

[yoavweiss]

Points raised at WebAppSec:

• We may want a future where we have different enforcement for different destinations. Maybe we can enable that through parameters? (e.g. IntegrityPolicy: destinations=(script;block image;warn))
• We should report if the violation is a report-only one or an enforced one
• No-cors assets should be blocked. The current algorithm doesn't cover it

[yoavweiss]

Another thought: An event here is redundant with a ReportingObserver. There's no reason to copy those over from CSP.

@mozfreddyb - do you agree?

[mozfreddyb]

Neither Firefox nor Webkit ship the Reporting API (or Reporting Observer). We should get clarity on whether there are plans to do so eventually or if this ends up being a hindrance. I'm going to ask around for Firefox.

[yoavweiss]

Neither Firefox nor Webkit ship the Reporting API (or Reporting Observer)

WebKit ships it (tests)

[yoavweiss]

Neither Firefox nor Webkit ship the Reporting API (or Reporting Observer)

WebKit ships it (tests)

Seems like it's implemented (but not shipped) in Firefox. Maybe y'all should just ship it? :)

Removed the event as it seemed spurious to what Reporting already does.

[yoavweiss]

• We should report if the violation is a report-only one or an enforced one
• No-cors assets should be blocked. The current algorithm doesn't cover it

Done

[yoavweiss]

• We may want a future where we have different enforcement for different destinations. Maybe we can enable that through parameters? (e.g. IntegrityPolicy: destinations=(script;block image;warn))

I'm not sure what to do about this one - if that syntax works, maybe we should add a processing step such that any parameter that's not "block" would cause the value to get dropped?

Also, if we're going with this, do we need an "enforcement" key?

@camillelamy @mozfreddyb - I'd love your opinions

[tomrittervg]

• We may want a future where we have different enforcement for different destinations. Maybe we can enable that through parameters? (e.g. IntegrityPolicy: destinations=(script;block image;warn))

I'm not sure what to do about this one - if that syntax works, maybe we should add a processing step such that any parameter that's not "block" would cause the value to get dropped?

Also, if we're going with this, do we need an "enforcement" key?

@camillelamy @mozfreddyb - I'd love your opinions

Freddy is out and I know you're trying to keep momentum; I was not at the meeting but I looking at our original notes, we did have a separate list of destinations for different enforcement levels, so I think this is still desirable.

Maybe instead of destinations and enforcement, we could have destinations-block which would be a list of destinations, and any other unrecognized key would be ignored (which I think is the behavior now?)

Then in the future we could add a destinations-warn list. Would that work?

[yoavweiss]

Maybe instead of destinations and enforcement, we could have destinations-block which would be a list of destinations, and any other unrecognized key would be ignored (which I think is the behavior now?)

Then in the future we could add a destinations-warn list. Would that work?

Yeah, that would work for me. (maybe calling it blocked-destinations instead..)

[camillelamy]

Having destinations-block and extending with other kinds of destinations if needed seems good to me.

[yoavweiss]

@mozfreddyb @annevk - Friendly ping on this review :)

[annevk]

No. https://fetch.spec.whatwg.org/#header-list-contains already does the case-insensitive match. You just have to write it as `Integrity-Policy` (bit annoying with backslashes if you want to stay full Markdown). This will have to be redone.

[yoavweiss]

Landed on "If |headers| contains ``integrity-policy``". Does that work?

[annevk]

A way to satisfy mt and I would be to define the actual type in Fetch. A middle ground might be a note. But this seems okay.

[yoavweiss]

I can do that as part of the Fetch integration as a followup