W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

[SRI] providing good defaults when the expected content type is missing?

From: Francois Marier <francois@mozilla.com>
Date: Tue, 30 Dec 2014 14:57:10 +1300
Message-ID: <54A20676.9090307@mozilla.com>
To: public-webappsec@w3.org
The spec currently says:

"The hash function and digest MUST be provided in order to validate a
resource’s integrity. The MIME type SHOULD be provided, as it mitigates
the risk of certain attack vectors."

I've added a warning in the Firefox devconsole when the content type is
missing, but I was just thinking that in a lot of (most?) cases, we
could provide a good default for developers and let them override it if
they want to.

Specifically, I'm thinking that when the integrity attribute is on a:

- <script> tag: default the expected type to "application/javascript"
- <link rel="stylesheet"> tag: default to "text/css"

I can see two consequences of this:

1. It means that a developer who forgets to include the content type
would still get the benefits of an explicit ct parameter.

2. It means that to opt out of content-type matching, we would need to
add a new kind of syntax (maybe something like "ct=*").

Consequence 1 would be nice since SRI would be stronger by default but
maybe #2 would be a problem in practice?

Are there any other potential problems I'm not thinking of?

Received on Tuesday, 30 December 2014 01:57:41 UTC

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