cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Chase <cha...@chromium.org>
Subject Proposal for CSP support
Date Thu, 19 Feb 2015 21:55:23 GMT
I'm interested in full-blown support for CSP (Content Security Policy) in
Cordova.  While we're close to having new and improved whitelist
functionality, there are gaps in what the whitelist is able to protect
against. In particular, inline script and eval() are higher risks that are
not addressed by whitelists.

Many Cordova apps may use only static content, or not include any
third-party content.  However, there are certainly examples of apps that
need to include user input/third-party content, mixed with the app's own
HTML content.  In some cases, platforms may even restrict functionality
(see [1]). I think CSP is a compelling answer for these scenarios, and for
security in general for apps.

Assuming CSP support is valuable, the question is how to implement?
Support for CSP is not universal across platforms.  It is known to be
supported on Android (KitKat and later), iOS (since 7.1), and Firefox.
Where supported, it is typically via a HTTP response header, or a META tag
in the document.

I've done some investigation into feasible approaches.  As a result, I'm
proposing as below.

Long term goal:
Cordova supports CSP in apps *and* plugins, and is enabled/secure by
default.  Ideally, CSP rules can be configurable and automatically applied
to all content (i.e. so developers can fall into the pit of success)

Achieving this goal will likely require incremental progress over a number
of releases.  At a high level, first make changes so developers can
manually apply CSP to their apps.  Longer term, add support for
configurability and automatic application of CSP.

Short term plan:
- Change new app template to contain CSP meta tag with a default, secure
policy (i.e. no inline script, eval(), only local app content)
- Remove any blockers to default policy from framework and core plugins.
This would be a continuation of the work in CB-8210, applied to other
platforms.  For example, this would fix any framework code that relies on
sending javascript to be executed inline, from the native side
- Deprecate any framework APIs that allow less secure practices.  Many
already are marked as deprecated (at least on Android)
- Update docs/samples to include CSP, and clearly state that use of inline
javascript is deprecated

Long term plan:
- In a future major release, remove the previously deprecated framework APIs
- Define/implement a configuration model for CSP rules
- Implement a build/package step to apply configured CSP rules to all
content as meta tags.  Run-time support involves re-writing content, and/or
intercepting resource requests.  The feasibility of intercepting requests
is highly variable across platforms, at greater cost/complexity than
build-time.

I'm very interested in any comments on this proposal.  This includes
questions around use cases (missing or otherwise), different requirements,
technical concerns, .etc.

Thanks,
Jason
Google Cordova Team

[1] http://callback.markmail.org/thread/yxmmya2o2lc26tpi

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