The 6 Most Common Security Mistakes in Mobile Apps
When you release a mobile application to the world, one has to be aware that not everyone has good intentions. Security is one of those things that is often overlooked because it doesn’t directly affect the functionality of the app. Essentially, an application will work regardless of its security efforts.
User privacy however, is absolutely necessary and you must preserve the integrity of the data passing through your application.
We highly recommend that you carefully consider the level of security required when planning your application. You should clearly state your requirements in a gathering phase so that they can’t slip. Once implemented into the app, test them as you would with any other feature; would you ever release a shopping application without checking if the ‘Buy’ button works?
There are so many areas to take into account and this can sometimes be a little daunting. To help, we’ve compiled a list of what we feel are the most common mistakes, so that you can be prepared in advance and avoid them.
Unencrypted Connections
Most applications connect with one or more servers to store and retrieve information and communicate with other apps. The most common protocol for that is HTTP. Use the encrypted version, HTTPS for that. If you’re also using other protocols such as SMTP or FTP, that’s fine, just ensure you’re using the secure version.
Even if you’re not planning to transmit highly sensitive data, most applications send some sort of password or security token to identify their users, there is no excuse for not using an SSL/TLS anymore.
Validation Disabled on Encrypted Connections
Oftentimes developers know about the benefits of encrypted connections but during the development phase, they remove the certificate validation. This basically means, as long as the connection is encrypted, the application doesn’t check that it’s talking to the right counterpart. Even though that’s better than no encryption altogether, it doesn’t take advantage of the full protection TLS/SSL provides: this gives an opportunity to attackers to fool the application into believing they it’s connected the right server and thus getting access to confidential information.
It’s likely that the validation has been disabled because the development servers are not properly configured. We recommended that you always give a fully-qualified domain name to your development server and configure an SSL certificate, this way you will never need to disable certificate validation.
Embedded Passwords
Mobile applications can be disassembled. Some are more difficult than others, but an attacker with enough patience will be able to extract any information that you put into it.
Because of this, avoid embedding any passwords, security tokens or any other secrets that should not be known by the general public… because they eventually will.
Some third party services may require you to have an application token to authenticate with them. Follow the instructions on their website on how to configure and protect them correctly.
Data Leaks via Side Channels: Logging
Mobile applications have a logging facility, just like a web or server application. Logs are useful to understand the application’s internal states and the decisions taken during the development phase. However, logs are often not used once the application goes to the stores (well, except in some cases).
It is not uncommon that logs contain potentially sensitive data, such as personal user data, passwords or tokens. Our recommendation is that you programmatically enable/disable logging to console, so that you can disable it when shipping an application.
Open Interfaces Meant for Internal Use
Nearly all applications have a user interface (UI), and we often focus our security efforts there; What could a user with malicious intentions input to break the security?
It’s not uncommon though for apps to have other interfaces to interoperate with other applications on the device or within its own components. These are called providers or schemes depending on the platform and the implementation.
It’s recommended to make sure all providers and schemes are properly secured against malicious uses, and don’t assume that their user is the intended one. The operating system has mechanisms to secure these interfaces, so use them.
Mind the Server
It’s very common for an app to be developed in tandem with a backend server; to store information in a database and run some of the application’s logic. In order to be safe, you must also make sure that the server itself is well secured. The OWASP Top 10 project is a list of the most common server vulnerabilities and how to avoid them.
There are several common mistakes that can be easily avoided just by keeping them in mind. We hope this list will help you to improve your application’s security.
It goes without saying that if you’re particularly concerned about security, it is a good idea to have an independent professional security consultant help you during the requirement gathering and review your application after it’s completed. This is highly recommended (and maybe even legally compulsory depending on the countries) for applications handling highly sensitive data such as healthcare, insurance, banking, sexual preferences, etc.
Here at Mobile Jazz, we have a security team that can help you in selecting the appropriate level of security for your application depending on your needs. We can help to specify the requirements, incorporate the necessary security elements in your design, overlook the implementation and perform a security testing once the application is completed. For highly sensitive projects, we can also provide you with some recommendations on independent consultants that can oversee this process.
What other checks do you have in your app security checklist? We’d love to hear.
If you enjoyed this post, visit our blog for more.
