If ti has its own mime type, should it have its own extension as well? (I’m aware browsers wouldn’t pay attention to the extension)

@ljharb Having a separate extension would not help security-wise.

I'd be worried about this scenario:

1. a web service hosts uploaded files checks and uses mime.lookup to reject uploads of HTML, SVG, and JS files in accordance with recommendations.
2. the web service uses mime.lookup] to compute the Content-type header when serving an uploaded file
3. import-maps rolls out in browser with a .importmap extension
4. The maintainer updates to a new version of mime.lookup which maps .importmap to application/importmap+json.
5. An attacker uploads payload.importmap and exploits it via an injection vulnerability.

It's been best practice to not host third-party content on a sensitive origin for some time, but increasing the set of Content-type values that existing applications may unintentionally attach to hosted content is a risk factor.

@mikesamuel an extension is the typical way that servers decide which mime type to serve a file with; i'm not suggesting it would help security-wise, but i don't see how it'd hurt. (given that browsers would, just like with everything else, ignore the extension and only switch on mime type)

@ljharb

given that browsers would, just like with everything else, ignore the extension and only switch on mime type

Major frameworks fill in Content-type based on extension, so these are not orthogonal concerns. For example, the widely used send package uses extension checking. I believe that ends up being used to compute the mime-type for a lot of express apps, at least those that use serve-static.

but i don't see how it'd hurt.

I was trying to explain how in the scenario I just outlined. Was that not clear? Not convincing?

I don't think it's a big enough problem to warrant not recommending an extension.
But I also don't want to complicate this PR with something that will probably involve a lot of bikeshedding.

Fair that it doesn’t need to be in scope for the PR :-) but no, your example doesn’t seem any less problematic to me than if it uses the json extension.

@ljharb I don't think we disagree on any "... (should|must) ..." claims so unless you want me to expand on anything, have a great weekend.

Fair that it doesn’t need to be in scope for the PR :-) but no, your example doesn’t seem any less problematic to me than if it uses the json extension.

@ljharb
I think you're right. AFAICT, my cases all assume things I've assumed are outside the threat model I outlined at #105 (comment) : e.g. that there are few cases where an attacker can inject <script type=importmap ... but not <script>....
Sorry for the confusion.

#105 (comment)

We should probably not accept any JSON MIME type.

@mikesamuel, Does this mean that "if a MIME type is accepted as a JSON, then it shouldn't be accepted as an import map (and vice versa)"?
If so, I noticed that application/importmap+json is a JSON MIME type and thus we should consider another MIME type.
https://mimesniff.spec.whatwg.org/#json-mime-type

(Or just meant that "not all JSON MIME types should be accepted as import maps"?)