Repository navigation
Nosniffing for Worker Scripts #3255
Description
8.1.3.2 Fetching scripts says:
- Under "To fetch a single module script", step 8: "If any of the following conditions are met [...] The result of extracting a MIME type from response's header list (ignoring parameters) is not a JavaScript MIME type."
- There are no equivalent rules for classic or worker scripts.
Chrome would like to be more strict about the non-module scripts, too. On Chrome's beta channel, we see:
- ca. 0.01% of page loads contain worker scripts (workers or scripts loaded from workers) that would fail this check if it were applied.
- ca. 6% of classic, non-worker page loads contain scripts that would fail this check if applied
- of these, the vast majority ( ~3/4 ) are text/html
- ~1/4 text/plain
- ~1/10 application/octet-stream
- the rest is noise, <0.01%
These numbers would probably support blocking non-script MIME types for the "fetch a classic worker script" and "fetch a classic worker-imported script" cases, too, but not (yet) for all script types.
Would this make sense?
Activity
mikewest commentedon Nov 24, 2017
I do think this is a good idea. The numbers we have in Beta right now look pretty reasonable for the narrow case you've outlined (workers themselves, and scripts they import), and it would be nice to unify the requirements for workers and module scripts.
For the broader case of
<script>in general, I agree with you that we need to do more work evaluating the status quo before we can make any changes. ~6 is a lot of percent, and though my intuition is that a large chunk of thattext/htmlcan be attributed to ads, the number's significantly higher than I was hoping, and we're going to have to dig in a bit to see if there are subsets we can carve out. That said, iftext/html,text/plain, andapplication/octet-streamcomprise the majority, perhaps we could invert the checks to explicitly allow the javascript types and those three additional types, and block everything else?I'd be interested in opinions from other folks in @whatwg/security. Is this kind of restriction something other vendors would also be interested in experimenting with?
mikewest commentedon Nov 24, 2017
(@dveditz, @johnwilander, @patrickkettner)
annevk commentedon Nov 24, 2017
Mozilla is. We've been looking into this as well; @evilpie primarily (added the
text/csvrestriction on the Fetch side for all scripts).mikewest commentedon Nov 24, 2017
It would be interesting to find out if Mozilla's users are seeing similar ranges of scripts to Chrome's users. @evilpie, do y'all have any metrics in place for script content types?
evilpie commentedon Nov 24, 2017
I am always excited about restricting those MIME types further.
Sadly we don't currently have fresh metrics. Our old telemetry counter expired. We also didn't differentiate between the workers vs script etc. https://bugzilla.mozilla.org/show_bug.cgi?id=1399990 is going to add new telemetry.
I also got this information from HTTP Archive https://discuss.httparchive.org/t/can-you-get-a-list-of-non-standard-mime-types-used-for-js-scripts/1141
I think the most interesting take away is how common text/json seems to be.
bzbarsky commentedon Nov 28, 2017
It's interesting that the HTTP Archive data look quite different from @otherdaniel's telemetry data. Probably a matter of what happens when you weight by load frequency? How does Chrome's telemetry handle empty Content-Type headers?
mikewest commentedon Nov 29, 2017
I expect that frequency weighting will give radically different results than number of resources requested, yes. The data @otherdaniel pointed to is also from beta, not stable, which will certainly shift things a bit (though usually the same order of magnitude).
Code is here: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/AllowedByNosniff.cpp?rcl=189b14fddd21542f2a1c5d81286cf342bad3b428&l=58
Looks like the data doesn't include empty
Content-Type, which is certainly an oversight we should correct.I dug into this a bit earlier in the week, pulling a list of sites that triggered the metrics we have in stable from HTTP Archive, and loading ~7k of them from my workstation overnight (raw data in a Google Sheets doc) with a build that dumps a bit more detail about the requests. This also doesn't give us frequency-weighted data, but it's at least somewhere to start. Some highlights:
Types
(Random data in the "Analysis" tab of the sheet)
Content-Typeaccounts for ~13% of the requests.text/htmlaccounts for ~50%.application/jsonfor ~23%.text/plainfor ~5%.application/octet-streamfor ~4%.text/jsfor ~2%.Hosts
(Data in the "Hosts per Type" tab of the sheet)
application/jsonis dominated bygraph.facebook.com(e.g. the JSONP endpoint athttps://graph.facebook.com/?callback=jQuery2140942788649414716_1511786863676&id=http%3A%2F%2Fwww.theactivetimes.com%2F&_=1511786863677). Perhaps @hillbrad can hook us up with someone who could change that type when a callback is present? There are a few other services with similar characteristics for JSONP endpoints:secure.livechatinc.com,us-ads.openx.net,addthis.com,api.instagram.com,instagram.com,sharethis.com, and many more.text/html(e.g.https://ads.pubmatic.com/AdServer/js/gshowad.js). They don't appear to be anything other than server misconfigurations.s4.histats.comserves files likehttp://s4.histats.com/stats/0.php?2887713&@f16&@g1&@h1&@i1&@j1511787906552&@k0&@l1&@mDAD%20Soft%20Free%20Download%20Full%20Version%20Pc%20Games%20And%20Softwares&@n0&@o1000&@q0&@r0&@s0&@ten-US&@u1200&@vhttp%3A%2F%2Fwww.dadsoft.net%2F&@wastext/htmlfor no discernable reason.ib.adnxs.comserves an emptytext/htmlfile (http://ib.adnxs.com/async_usersync?cbfn=AN_async_load).sharethis.comon the other hand serves a hybrid HTML/JavaScript file astext/html(e.g.http://t.sharethis.com/1/d/t.dhj?rnd=1511786912267&cid=c010&dmn=www.stio.com). It would be useful to find someone there who would tell us why. (Also, their HTML version is broken, so.... I'm not terribly worried about breaking it. :) )ley8677 commentedon Dec 13, 2017
Also, their HTML version is broken, so.... I'm not terribly worried about breaking it. :) ) ????
mikewest commentedon Mar 21, 2018
I did a bit more research this morning via HTTP Archive: https://groups.google.com/a/chromium.org/d/msg/blink-dev/35t5cJQ3J_Q/jCHygAPuCQAJ
The high-level conclusion there is that Facebook and VK have ~widely used endpoints that serve JSONP as
application/jsonandtext/htmlrespectively.mikewest commentedon Mar 21, 2018
(And that not much else looks like it would break in a way visible to users)
Enforce strict MIME type checks for worker-imported scripts.
Enforce strict MIME type checks for worker-imported scripts
evilpie commentedon Jan 2, 2019
@mikewest Have you talked to any of those JSONP providers about changing their Content-Type to JavaScript?
32 remaining items
evilpie commentedon Feb 18, 2020
We intent to ship this change with Firefox 75. /cc @annevk
domenic commentedon Feb 18, 2020
I'll work on a spec PR
Enforce JS MIME type checking for worker scripts
Add MIME type checking for non-blob:/data: worker scripts
Add MIME type checking for HTTP(S) worker scripts
Add MIME type checking for HTTP(S) worker scripts
Add MIME type checking for HTTP(S) worker scripts
Add MIME type checking for HTTP(S) worker scripts
evilpie commentedon Jan 2, 2022
I wonder if we could get some kind of status update here. Seems like Chrome isn't shipping this yet. We just ran into a web compat issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1748157
evilpie commentedon May 16, 2022
@domenic Have you heard anything?
domenic commentedon May 16, 2022
I heard a few "I'll look into that", but nobody reached the level of following up, from what I can tell :(
Enterprise Policy for Worker script MIME type checking (lax/strict).
annevk commentedon Mar 31, 2025
At this point only the Chromium bug remains. So closing this. See also the related #8869.
Bug 1597188 [wpt PR 20294] - Add a runtime flag to enforce strict MIM…