Inline ES Modules
mikesamuel at gmail.com
Wed Jun 20 00:57:49 UTC 2018
Sorry for the confusion.
Nonces are just for elements with url attributes.
I mentioned nonces to point out that strict CSP policies can allow some
data: urls without having to explicitly whitelist or hash the entire
Separately I wanted to say that there is no incompatibility between the
goals of CSP and import statements that use a data: module specifier, since
we already trust the compilation unit and there's no actual network message
But there is a risk with the import operator since it's input is not part
of an already trusted input.
On Tue, Jun 19, 2018, 8:22 PM Darien Valentine <valentinium at gmail.com>
> Mike: Ah, cool, I didn’t realize that — I had thought that nonces were
> just for whitelisting inline script elements. How does one specify a nonce
> in association with a data URI? I’m having trouble turning up a description
> / example of how it would work. Or possibly I’m misunderstanding this quite
> a bit, hm ... I’m also confused by the relationship between import/import()
> and XSS that you’ve described.
> On Tue, Jun 19, 2018 at 8:06 PM Mike Samuel <mikesamuel at gmail.com> wrote:
>> CSP with data URIs is possible via nonce sources. For data: module
>> descriptors browsers could safely skip the CSP check since it doesn't allow
>> XSS unless one can already specify an import statement which typically
>> means one can specify arbitrary JS. That argument doesn't extend to the
>> import operator though so you'd have to tolerate assymetry there.
>> On Tue, Jun 19, 2018, 7:57 PM Darien Valentine <valentinium at gmail.com>
>>> Andrea: That is a really interesting approach. I would point out that
>>> using data URIs for js means the `data:` scheme has to be a permitted
>>> source for script-src. This allowance has roughly the same security
>>> implications as permitting `unsafe-eval`. I know most people aren’t using
>>> CSPs yet, but personally I’d be wary of a solution that makes it harder to
>>> adopt a strong CSP.
>>> A super dorky/tangential aside that probably doesn’t matter at all but
>>> contradiction between the IANA media type registry and the HTML 5 spec with
>>> regard to the "correct" media type to use for JS. RFC 4329 says
>>> sure though) that this is because it’s the most backwards-compatible value.
>>> Given that the media types registry seems to be basically dead to web
>>> standards (if we follow the registry we can’t serve or post a bunch of
>>> media types acknowledged or defined by web standards at all, including
>>> image/webp, application/csp-report, etc) and the code has to run in a
>>> browser, I’d tend to think HTML is the better spec to follow ... though I
>>> guess when two specs contradict each other it’s hard to make an objective
>>> case for one being more authoritative. (I’d be curious if there’s a
>>> specific reason you know of to prefer to RFC definition though. When
>>> standards don’t align it breaks my tiny heart.)
>>> On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi <
>>> andrea.giammarchi at gmail.com> wrote:
>>>> sorry, I meant:
>>>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <
>>>> andrea.giammarchi at gmail.com> wrote:
>>>>> I think these are all nice to have features, but I also think we have
>>>>>> all the primitives we need to make it happen via pre-processing.
>>>>> I meant even synchronously, with a pre-processor that replace the
>>>>> imported module with
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss