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`.

Okay, then your proposal is insufficient.

What if someone was not even aware of CSP? Or someone had limitation on server configurations they can change? Again, most websites don't deploy CSP correctly. **As a general rule, we shouldn't be introducing new features that are vulnerable by default**.

> > 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 idea of using file extension has been rejected multiple times: see https://github.com/w3c/webcomponents/issues/839#issuecomment-536428267 for example.

Please be mindful of others' time and read the whole thread before making a proposal that has known issues.

> 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.

I don't follow. Are you saying that people would be relying on build tools to generate CSP headers. That doesn't compute because CSP headers are often set via server configurations.

This is, however, precisely why we don't want to rely on CSP. We want the content which gets served to the client to have its expected type hard-coded in its source. That's how we safe guard against random resources suddenly start executing arbitrary code.

For example, a service I created a while ago relies on JSON files being served by Apache inside a special directory. This directory is the only writable directory that's also publicly accessible in the entire service. All files in this directory are JSON and therefore are not executable (either in client or server side). If we started loading JSON files from this directory in the said service as JSON modules, it would be a strict security regression because now those JSON files could execute scripts if there were some bugs which allowed attackers to write to this directory.

-- 
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-555336461