-
Notifications
You must be signed in to change notification settings - Fork 357
Description
[See #636 (comment) about adding examples. Below is the old purpose of this issue.]
3.3.1. Should response to request be blocked due to nosniff?
Run these steps:
1. If response’s header list does not contain `X-Content-Type-Options`, then return allowed.
2. Let nosniff be the result of extracting header values from the first header whose name is a byte-case-insensitive match for `X-Content-Type-Options` in response’s header list.
3. If nosniff is failure, then return allowed.
4. Let mimeType be the result of extracting a MIME type from response’s header list.
5. Let destination be request’s destination.
6. If destination is script-like and mimeType (ignoring parameters) is not a JavaScript MIME type, then return blocked.
7. If destination is "style" and mimeType (ignoring parameters) is not `text/css`, then return blocked.
8. Return allowed.
Many websites will use a blanket "nosniff" option because it's being pushed as a recommended security measure. However, many sites also do not supply a content-type header with every document/response returned. As a result, any script or style that would not have a supplied content-type in the header would, according to this spec, be blocked. Blocking should only occur on a mis-match of MIME type in the intention of this spec as I understood, and not when the MIME type is missing altogether. Since you can't compare between two values when one of them is missing, it should be allowed.
I suggest adding an additional step between 4 and 6:
If mimeType is empty, then return allowed.