A colleague invited my attention to this article. I was engaged by this headline :
“The best way to keep mobile apps safe is to secure the services they connect to.”
Perhaps. In any case, this is good treatise on the security of client-server applications.
However, the quote seems to suggest that the risk is that client mobile apps are being contaminated by connecting to rogue services. In fact, the risk to the enterprise is more likely that rogue or compromised apps on mobile devices will leak sensitive data into the network. Even that risk ranks after the risk to the user that rogue apps will incur charges; this is one way that rogue apps are being monetized.
Therefore, the issue for the enterprise is not protecting the client app from the server, or any server, but protecting the application and its data on the server. The best way to do that is to ensure that the server will only accept connections from known and trusted clients. Said another way, use crypto to authenticate the code in the app to ensure that it is the code that you think that it is; then use crypto to authenticate the client application and bind it to the server end-to-end.
The owner (not necessarily the user) of the mobile device must get the client app from trusted sources, e.g., iTunes, the enterprise itself, and protect it from contamination or compromise from other apps. (If the enterprise does not yet know how to protect its servers, this discussion is premature.) Again, trusted apps from trusted sources via trusted transport or packaging. (This assumes that the enterprise has a sufficiently well-controlled development process that it can produce application programs that do what, and only what, it intends.)
To protect against any unacceptable residual risk of a rogue application on the mobile device, one should prefer a mobile device operating system, e.g., iOS, that provides good process-to-process isolation. For highly sensitive applications one should use a mobile device dedicated to that application. Hardware is cheap. This is a cost of high security and must be balanced against the risk or sensitivity of the application. (One should not use a shared device and then whine about its operating system.)