cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kerrishotts <>
Subject [GitHub] cordova-docs pull request #703: CB-12770: revise security documentation
Date Mon, 08 May 2017 21:32:02 GMT
Github user kerrishotts commented on a diff in the pull request:
    --- Diff: www/docs/en/dev/guide/appdev/security/ ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when
developing a Cordova application. Please be aware that security is a very complicated topic
and therefore this guide is not exhaustive. If you believe you can contribute to this guide,
please feel free to file an issue in Cordova's bug tracker under ["Documentation"](
 This guide is designed to be applicable to general Cordova development (all platforms) but
special platform-specific considerations will be noted.
     ## This guide discusses the following topics:
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
    +## General Tips
    +### Use InAppBrowser for outside links
    +Use the InAppBrowser when opening links to any outside website. This is much safer than
whitelisting a domain name and including the content directly in your application because
the InAppBrowser will use the native browser's security features and will not give the website
access to your Cordova environment. Even if you trust the third party website and include
it directly in your application, that third party website could link to malicious web content.
    +### Validate all user input
    +Always validate any and all input that your application accepts. This includes usernames,
passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and
JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`),
this validation should also be performed on your server, especially before handing the data
off to any backend service.
    +> **Tip**: Other sources where data should be validated: user documents, contacts,
push notifications
    +### Do not cache sensitive data
    +If usernames, password, geolocation information, and other sensitive data is cached,
then it could potentially be retrieved later by an unauthorized user or application.
    +### Don't use eval()
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly
can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +### Do not assume that your source code is secure
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged
in a native container, you should not consider your code to be secure. It is possible to reverse
engineer a Cordova application.
    +A sampling of what you should not include in your code:
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +### Do not assume storage containers are secure
    +Even if a device itself is encrypted, if someone has access to the device and can unlock
it, you should not assume that data stored in various formats and containers is safe. Even
SQLite databases are easily human readable once access is gained.
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you
were storing passwords, keys, and other sensitive information, the data could be easily extracted,
and depending on what was stored, could be used against your app and remote servers.
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable
to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted
SQLite database. The underlying storage of the device may in fact be encrypted (and so it
would be inaccessible while the device is locked), but once the device decrypts the file,
the contents themselves are mostly in the clear. As such, the contents of `localStorage` can
be easily read and even changed.
    +## Plugins and Security
    +Due to the way the native portion of Cordova communicates with your web code, it is possible
for any code executing within the main webview context to communicate with any installed plugins.
This means that you should _never_ permit untrusted content within the primary webview. This
can include third-party advertisements, sites within an `iframe`, and even content injected
via `innerHTML`.
    +If you must inject content into the primary webview, be certain that it has been properly
sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own;
use a vetted third-party library instead!_
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins
for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +## Content Security Policy
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism
you can use to control trusted sources of content. You can restrict various content types
and restrict the domains from which content can be loaded. You can also disable unsafe and
risky HTML and JavaScript, which can further increase the security of your app. The CSP tag
should be placed in your app's `index.html` file.
    +> **Note**: If your app has multiple HTML files and navigates between them using the
browser's navigation features, you should include the CSP in each file. If using a framework,
you only need to include the CSP on `index.html`.
    --- End diff --
    Yep, you're right. I'll change that. :-)

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message