Github user kerrishotts commented on a diff in the pull request:
https://github.com/apache/cordova-docs/pull/703#discussion_r115358538
--- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
@@ -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"](https://issues.apache.org/jira/browse/CB/component/12316407).
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`.
+
+The CSP that Cordova typically uses in its templates looks like this
(indented for clarity):
+
+```html
+<meta http-equiv="Content-Security-Policy"
+ content="default-src 'self' data: gap: https://ssl.gstatic.com;
+ style-src 'self' 'unsafe-inline';
+ media-src *">
+```
+
+The above CSP enforces the following:
+
+* Media can be loaded from anywhere
+* Styles can only be loaded from the app itself (`'self'`)
+* Inline styles are permitted (`'unsafe-inline'`)
+* All other network requests can only be from (or to) the app itself,
`data:` URLs, the iOS Cordova bridge (`gap:`), or to Android's TalkBack
accessibility feature (`https://ssl.gstatic.com`)
+
+By defalt, using this CSP will prevent _inline JavaScript_ and `eval()`.
There are occasions, unfortunately, where a library may need one or the other,
but this is rare and becoming moreso. If you must override this functionality,
you can do so using the `script-src` directive.
+
+You should fully understand the CSP tag and the various directives that
can be specified. More documentation is available at [Content Security
Policy](https://developers.google.com/web/fundamentals/security/csp/) (via
Google Developers) and Mozilla's [Content Security Policy
(CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) article.
+
+> **Warning**: Failure to include `gap:` in `default-src` may result in
the app failing to work properly on iOS.
+
+> **Tip**: If you're using web sockets, include `ws:` (`wss:` if using
SSL) in the `connect-src` directive.
+
+### Debugging the CSP
+
+Chances are good that when you add a CSP to your app, you'll encounter
some problems. Thankfully both Google Chrome's developer tools and Safari's web
inspector will make it glaringly obvious when the CSP has been violated. Watch
the console for any violations, and fix accordingly. Generally the error
messages are pretty verbose, indicating exactly what resource was rejected, and
why.
+
+TODO: include example
--- End diff --
;-) Will do :-)
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
