Repository metrics
- Stars
- (2,051 stars)
- PR merge metrics
- (Avg merge 66d 10h) (4 merged PRs in 30d)
Description
[See https://github.com/whatwg/fetch/issues/636#issuecomment-346558085 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.