From e9a69883e39d22d46a6543112063f823d09ebac4 Mon Sep 17 00:00:00 2001 From: Francois Marier Date: Tue, 19 May 2015 21:58:37 +1200 Subject: [PATCH] SRI: Remove problematic headers section (fix #305) --- specs/subresourceintegrity/spec.markdown | 21 +++------------------ 1 file changed, 3 insertions(+), 18 deletions(-) diff --git a/specs/subresourceintegrity/spec.markdown b/specs/subresourceintegrity/spec.markdown index 6f2234f7..99d27f39 100755 --- a/specs/subresourceintegrity/spec.markdown +++ b/specs/subresourceintegrity/spec.markdown @@ -336,30 +336,15 @@ only deliver integrity metadata on a [potentially secure origin][]. See [uri-origin]: http://tools.ietf.org/html/rfc6454#section-4 [Non-secure contexts remain non-secure]: #non-secure-contexts-remain-non-secure-1 - -Certain HTTP headers can also change the way the resource behaves in -ways which integrity checking cannot account for. If the resource -contains these headers, it is ineligible for integrity validation: - -* `Authorization` or `WWW-Authenticate` hide resources behind a login; - such non-public resources are excluded from integrity checks. -* `Refresh` can cause IFrame contents to transparently redirect to an - unintended target, bypassing the integrity check. - The following algorithm details these restrictions: 1. Let request be the request that fetched resource. -2. If resource contains any of the following HTTP headers, - return `false`: - * `Authorization` - * `WWW-Authenticate` - * `Refresh` -3. If the [mode][fetch-mode] of request is `CORS`, +2. If the [mode][fetch-mode] of request is `CORS`, return `true`. -4. If the [origin][fetch-origin] of request is +3. If the [origin][fetch-origin] of request is resource's origin, return `true`. -5. Return `false`. +4. Return `false`. Step 3 returns `true` if the resource was a CORS-enabled request. If the resource failed the CORS checks, it won't be available to us for integrity