Re: [w3c/webcomponents] HTML, CSS, and JSON modules shouldn't solely rely on MIME type to change parsing behavior (#839)

> In addition, this proposal would make CSP directives affect how the served content is parsed (or not parsed), meaning that depending on CSP directives you may have on a website, the content may start executing where you were not expecting to execute.

I think there may be some confusion, I'm only proposing `*.json application/json` be applied as an assertion, it does not actually change the type, probably a better name would be `allowed-content-types`.

For example if I have the policy `*.json application/json` and I fetch `foo.json` then if its content type does not match `application/json` then it will be rejected by the CSP causing the attempted fetch to fail.

This doesn't change semantics of the content, just rejects it if it doesn't meet some criteria (which is exactly what CSP does for other resources).

For imports specifically a strict default could be applied that ensures that if a policy exists then the resource must actually match one of policies patterns to be accepted as a non-javascript type.\*

\* Ideally this would apply to all resources not just imports but it seems like a kinda large barrier to adopt JSON modules which is why I'm suggested doing it as a special stricter case.

> This approach is problematic because it adds more distance between where the type is declared & where it is used.

Although file extensions don't mean anything on the web, almost all developers would expect `.json` to be `application/json`. It seems only natural that such a policy would be enforced at a higher level that developers do not need to concern themselves with on a day to day basis.

The most likely scenario is that people just add it into a build tool to automatically transform. But this seems kinda pointless because developers will in no way be thinking more about the security with that approach than with the CSP approach.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/839#issuecomment-555302876