Delivering an engaging experience for mobile computer users is an enjoyable aspect of solution development but should not be regarded as the top priority. Security should be front and center in every application development and release cycle. Failure to prioritize data and device security above all else can make customers vulnerable to multiple issues, all of which can result in a loss of customer trust and loyalty as well as financial consequences for developers, customers, partners and end-users depending on the application’s use case.
Therefore, it is critical that developers keep these four considerations in mind when reviewing the strength of their mobile applications’ security features:
Always choose security over convenience
Any application programming interface (API) keys used to communicate with third-party services included within your application binary are inherently insecure. Developers will try to obfuscate keys within their applications using ProGuard or some proprietary mechanism, but any complications can be undone with enough effort.
It is important to ensure appropriate restrictions are placed on the use of any API key. For example, if you are creating a web application, then only handle requests originating from specific domains or IP addresses. For native applications, you can restrict the key based on each application’s bundle identifier or package name and signing certificate, ensuring that only applications signed by yourself are able to use your API key.
When third-party services do not offer sufficient restrictions on your API key, consider proxying calls through any of the large cloud providers who do. Never implement your own identify mechanism. While it might be tempting to create a simple name and password system for your users, this is very difficult to implement securely. If you need to authenticate your application users, opt for any of the trusted identity providers, for example, active directory (AD) in a corporate environment or Gmail or Apple ID for consumer applications.
Secure your signing keys and development infrastructure
It goes without saying that any keys or credentials used by your application, including the keys used to publish and sign your application, should never be added to a public source code repository. Even adding keys to private repositories poses a risk since you might choose to open source your application at a future date. It is also possible the code could be exposed or accidentally shared by a developer.
Production keys should only be accessible to engineers responsible for building the production app. When providing developers with test keys, ensure they are limited to the functionality they require. Keys should always be stored in separate files and rotated periodically. Remember, many keys for third-party applications will be tied to billing information, so there could be financial implications even if there is no data loss.
Take advantage of static analysis tools to identify potential issues with your application
In an ideal world, all applications would be submitted for penetration testing prior to launch to minimize code issues that could lead to security breaches. An entire industry has developed around pen testing, but most developers will not have the budget to test each release.
Open-source tools exist to statically analyze your code for any security issues that could be exploited and should be included in your development and release process. Try to develop a culture around security best practices because no developer, even the most experienced, can produce perfectly secure code every time.
Prevent data leakage
Logging is great. Logs contain an incredible amount of information, some of which could help an attacker probe your application for weaknesses. Obviously, secure information should never be logged. But even innocuous information could give away the architecture of your application or libraries used, which in turn could contain vulnerabilities.
File storage is another way that applications can unintentionally share data. If your application writes or reads files to a folder that is accessible to other applications, then the files you write are available to others and the files you read in from those shared folders are subject to tampering by nefarious applications.
Always remember, as a developer, you are the first step in creating secure mobile applications. However, creating and maintaining a security culture across the entire development and release team is essential to producing applications customers can trust.
To learn more about creating secure mobile applications, click here.
