Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id A3EFE200C6E for ; Mon, 8 May 2017 23:29:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A2763160BBF; Mon, 8 May 2017 21:29:07 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E8D6B160BA2 for ; Mon, 8 May 2017 23:29:06 +0200 (CEST) Received: (qmail 44889 invoked by uid 500); 8 May 2017 21:29:01 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 44874 invoked by uid 99); 8 May 2017 21:29:00 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 May 2017 21:29:00 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 9BC29DFBAB; Mon, 8 May 2017 21:29:00 +0000 (UTC) From: kerrishotts To: dev@cordova.apache.org Reply-To: dev@cordova.apache.org References: In-Reply-To: Subject: [GitHub] cordova-docs pull request #703: CB-12770: revise security documentation Content-Type: text/plain Message-Id: <20170508212900.9BC29DFBAB@git1-us-west.apache.org> Date: Mon, 8 May 2017 21:29:00 +0000 (UTC) archived-at: Mon, 08 May 2017 21:29:07 -0000 Github user kerrishotts commented on a diff in the pull request: https://github.com/apache/cordova-docs/pull/703#discussion_r115357795 --- 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. --- End diff -- Yes, this needs to be worded better and have some concrete examples. :-) I think "caching" is the wrong word here (this was copied from the previous version) -- "store" is probably more accurate. I _think_ attacks would either have to be device-in-hand attacks (since you'd need to get into the file system -- that's when you hope the device is protected with a pin & is encrypted!) or malware / viruses that abused some security hole (or ran amuck on a rooted/JB'd device). OR, if the app stored data in a public area on the file system (say, on Android), that would be risky too. (Hopefully no one would do that, though...!) So yes... more examples of what is meant by this would be good. --- 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 infrastructure@apache.org or file a JIRA ticket with INFRA. --- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org For additional commands, e-mail: dev-help@cordova.apache.org