Posted By: Jason
When developing mobile apps, many coders are under such pressure to get the app out of the door, they overlook key mobile security best practices.
That creates a headache for businesses down the line, because a major security breach can have serious implications for your apps adoption rates, and may even render the entire project damaged beyond repair.
Fortunately, securing your mobile app doesn’t have to be difficult. If you follow these five simple rules, mobile application designers can deploy secure and stable apps into the marketplace that users can enjoy without risking data loss.
1. Secure on-device token storage
If you have to store OAUTH tokens within your app, be careful where. Many developers have a habit of leaving OAUTH tokens exposed and vulnerable to attack. To help mitigate the risk, you should always store tokens on the local device in one of two locations: for IOS devices – The iOS Keychain and for Android devices – Shared preferences.
2. Always protect sensitive data
If there is one thing you don’t want to happen, it is the exposing of sensitive user data. But it could occur, especially if you don’t take care when storing sensitive data.
A good rule of thumb when developing mobile apps is to assume that there is no such thing as secure local storage; you should always aim to store this kind of data off the device and in the cloud. If you really need to store information locally, then you should encrypt it using either the Android or iOS encryption libraries. And don't forget to encrypt communications between your app and server as well.
3. Dumb clients are best
When you build out your application, make sure you don’t leave the crown jewels on display. The presentation-layer is not a good place to keep the logic of your code. These days it is all too easy for hackers to reverse engineer code to see how an app works. If that information falls into the hands of an attacker, you could be in big trouble.
Always ensure that your logic is kept in the data layer or business layer and keep the presentation layer for what it is designed for: presentation code.
4. Be careful who you trust
Developers have become used to reusing code and packages from third party libraries. While this is fine and can speed up development time, you should be aware of the security implications. If you use code and you don’t understand exactly what it is doing, you shouldn't be putting it in your app.
Always make sure you download packages from a trusted source and review the code before placing it in your app.
5. Pre-delivery checklist
OK, so your app is finished and ready for production. However, before you sign-off your app, it's a good idea to test the underlying code is secure and can withstand a few basic attacks.
Test your app with randomised or unexpected inputs, this tests for memory leaks and failing code assertions which could allow an attacker access to your data.
Improper input handling
You should ensure your app can withstand a wide range of attacks. XML injection, SQL injection, HTTP verb tampering and buffer overflow are just some of the hacking techniques you should be testing for.
CSRF cross-site request forgery
CSRF tricks the user into submitting a malicious request, by inheriting the identity and security privileges of a legitimate user to carry out an undesired function on the user's behalf. While these attacks are rare on mobile devices, they are possible and should be tested for.
Manually test SSL/TLS for weakness
SSL has long been a target for hackers looking to access systems. So you should always ensure that your protocols, ciphers and renegotiation are configured correctly.
This article shows you how to manually test your SSL/TLS stack for the most common weaknesses.
If you don’t have a large security team on hand to test the security of your app, it's a good idea to invest in mobile app security testing software. Checkmarx, monitors code as you write it, pointing out errors and recommending solutions as you go. A small investment in Checkmarx could save you a fortune in development time and lost revenue in the long run.