Skip to content
This repository was archived by the owner on Apr 10, 2025. It is now read-only.

Handling Subresource Integrity

Jump to bottom
Otto van der Schaaf edited this page Jan 14, 2018 · 7 revisions

(Work in progress https://docs.google.com/document/d/1EKRzys4OYaeYdCUHyOcoE-mergc_wvS2SNfBtBdc7n0/edit?usp=sharing)

Design Doc: PageSpeed Optimization Products and Subresource Integrity (SRI)

Introduction

Currently, PageSpeed optimization is unable to understand "integrity" html tag attributes or "Content-Security-Policy: require-sri-for [target];" type response headers. Ideally, the framework would be aware of these, and adjust its behaviour. https://www.w3.org/TR/SRI/ states:

Proxies

Optimizing proxies and other intermediate servers which modify the responses must ensure that the digest associated with those responses stays in sync with the new content. One option is to ensure that the integrity metadata associated with resources is updated. Another would be simply to deliver only the canonical version of resources for which a page author has requested integrity verification.
To help inform intermediate servers, those serving the resources SHOULD send along with the resource a Cache-Control header with a value of no-transform.
Also, see the introducation for the design of CSP handling: https://github.com/apache/incubator-pagespeed-mod/wiki/Design-Doc:-Brainstorming-PageSpeed-Optimization-Products-and-Content-Security-Policy

Interaction

PageSpeed Optimization products respect Cache-Control: no-transform by default: https://www.modpagespeed.com/doc/configuration#notransform Basically, PageSpeed Optimization has two modes of operation regarding optimization:

HTML-contextual optimization (the default)

In this mode we apply changes to html and replace resource urls, where we also consider the html context, leading up to more optimization opportunities. We will generate different resource urls and responses for different user-agents. In this mode the product should be aware of any integrity attributes. When we see one there are two options: Back out of optimization and leave the resource alone. Note that In-Place resource optimization may still apply when we do this (see below). Recompute the integrity attribute value when we have an optimized version

In-Place resource optimization.

We enhance delivery for resources like javascript, css, and images by serving a smaller, faster version. Responses will potentially be different per user-agent. The spec guards against breaking pages by specifying that any resources that have an integrity hash declared in html SHOULD be accompanied with Cache-Control:no-transform when served. However, the first issue has been filed, and it seems that this may be a fragile assumption for optimization products running in a proxy. Therefore it is worth considering our options to make this more robust. TODO(oschaaf): what can be done

Fetching our inputs

TODO(oschaaf): consider if the product should be able to verify original integrity attributes before stripping them or updating them with new values.

Going forward

At a high level:

  • The first step could be to make sure that we do not break pages by making them violate SRI integrity hashes. In the html flow, we can leave html tags with integrity attributes alone. The in-place flow may be challenging though.
  • The second step should be a filter that is able to strip input SRI attributes, but only if we can verify integrity on behalf of the user-agent.
  • The third step should be to add the capability of automatically adding integrity attributes
  • The last step should be to add integrity attributes on any of resources we inject ourselves. TODO(oschaaf): think about CSP part to this.
Clone this wiki locally