cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: How to handle CSP for XHR in Cordova 4.0
Date Fri, 12 Dec 2014 16:54:42 GMT
I'm fine with 1. coupled with a default CSP in the template application.

For older apps not written from scratch, we can perhaps strongly suggest
installing the legacy-whitelist, which would change the default-open
behaviour to default-closed.

Together, that would give sensible defaults that aren't open-to-everything?


On Fri, Dec 12, 2014 at 9:13 AM, Ian Clelland <>

> I'm just building the new optional whitelist plugins for Cordova Android
> and iOS 4.x, and I'm thinking about how to encourage developers to use CSP
> for network requests, as opposed to a
> Cordova-implemented-whitelist-which-probably-leaks-like-a-sieve.
> (Note: This is really just about things like XHR requests, <img> and
> <script> tags, etc, which are historically the only things that we've
> reliably been able to filter out. Other classes of network requests just
> bypass all of our code anyway, which sucks, and frame navigation and
> external application launches are already well handled by the framework).
> The policy I've implemented on the unplug-whitelist branches, which at
> first thought at least *sounds* sane, is that network requests are blocked
> by default. (At least all of the ones that we can intercept). That way, a
> plugin, such as the legacy-whitelist plugin, can open up access to specific
> resources, and the fallback is safety.
> To use CSP, though, we have to open up access to the outside, and we don't
> necessarily know what the developer wants to open (the whole point is that
> they specify in the HTML, not in a config file.) The easiest way is to open
> up access to *all* resources to the webview, and then restrict it through
> the CSP header/meta-tag, which does a better job of blocking those requests
> than we do in any case.
> I think that we want to encourage developers to use CSP, for a lot of
> reasons, but I'm going to have to do one of these things, and I'm not
> entirely sure which is the right one:
> 1. Open access to all network resources by default in Cordova 4.x.
>   * This doesn't apply to navigations, or launching other apps. They're
> still blocked by default.
>   * Any plugin implementing shouldAllowRequest would still be able to turn
> this into a disallow-by-default whitelist
>   * We can't block everything anyway (see websockets, audio/video streams /
> probably more), so it removes the illusion that we can.
> 2. Make another whitelist-y plugin, something like "org.apache.cordova.csp"
> that exists only to open up access to network resources. Direct all users
> who want to use CSP to install that plugin first
>   * It's a 4th network plugin (after legacy-whitelist, navigation-whitelist
> and intent-whitelist)
>   * Adding it doesn't actually add any CSP protection, so it probably needs
> a better name
>   * It's an extra step that may confuse people and limit adoption
> 3. Do something crazy. Maybe a CSP plugin that automatically creates CSP
> tags *and* updates the XHR whitelist, both from config directives.
>   * Lots more work
>   * We probably don't know enough about real requirements to get this right
>   * If CSP is doing its job, then the XHR whitelist isn't needed anyway; it
> would just be another layer that isn't doing anything different.
> I'm leaning towards #1, but its a it's a decision that we really should
> think about and decide on-list before moving forward.
> Ian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message