10 Most Common App Security Mistakes

Why Mobile App Security?

App security mistakes for Android and iPhone are generally a lesser prioritized area for a mobile developer, mostly because due to the time pressure. It does not usually get what it deserves in project plans. Moreover, in case of absence of a security owner in project teams, no one claims responsibility. That’s why mobile app security is a matter of attention left only to the developer’s initiative.

Security and Usability are two concepts that are inversely related. Highly secure solutions require additional processes and flows. However, most business units, working directly with consumers, don’t consider app security as the first priority.

In practice, nobody brings out a security concern unless something really goes wrong in case of “hacking”. Most application developers are not taking care of specific Android security and iPhone security tests. (Application Security Test).

Always keep in mind the principle that No app is %100 safe!

icloud-security-risk-1024x426

What Should You Do for App Security?

Our purpose is to make your app more secure than others by using quick and simple features, hence discouraging the hackers to mess with your mobile application. Make your app ready for mobile security. Here are the 10 Most Common App Security Mistakes:

1. Data Store Approach: First of all, sensitive data should not be stored on the device during runtime as much as possible. Data can be processed in case of need and should be deleted immediately when not needed. In case of a data storage need on the mobile device, data should be encrypted and stored in the documents folder. Passwords should be stored in KeyChain for iOS and KeyStore for Android app security. This is also important for app store security checks.

2. Missing front-end validation: Missing data entry validation causes both security and formatting issues. These may be things like letting alphanumeric values in numeric fields, missing masking on formatted fields, not checking for high risk character values such as <>` ” ()|#. Such missing validations may cause security breaches by allowing remote code execution or unexpected responses.

3. Server Based Controls: Application development is a client side operation. Server side is the place where you should store and manage the data. Server side checks should be applied regardless of channel (mobile, web, etc…) for data security and formatting. We do not mean iCloud keychain or a similar feature, please take care. This is about the app-specific backend security. There are also security concerns for Apple iCloud, however this is Apple’s work to do it more secure!

4. SSL: HTTPS must be used for secure transmission of sensitive information. If possible, a custom certificate should be used instead of the certificates from the built-in device certificate store. The certificate that is unique to the app and the server should be embedded inside the app.

5. Obfuscation: It is very important especially for Android apps to go through obfuscation. If script files are also used in parts of the app, these files should be taken through obfuscation as well.

6. Comment Lines: Explanatory data, included as comment lines may be viewed by others if the application is decompiled. This is very simple but a common mistake both for Android and iOS apps. This does not mean that you shouldn’t use comments during app development, just don’t forget to remove them from the production version of your app.

7. Excessive Permissions: When editing permission preferences for Android apps, only the permissions that are absolutely needed should be enabled. Permissions with access to personal information, such as “access to contacts”, should be avoided as much as possible for Android app security. If anything goes wrong, there is less chance of a data breach.

8. Encryption: The key used in encryption should also be encrypted and stored in secure storage. The installation file should also be obfuscated. Another dangerous practice that should avoided is the downloading of the encryption key from server during runtime.

9. Rooted/Jailbroken Devices: It is not possible to store totally secure data in rooted devices as root permissions provide unlimited access to the device filesystem and memory. However, it is possible for developers to check if the device is rooted or not. This risk should be noted and evaluated based on project scope for all flows and processes.

10. Application Tampering Protection: The application binary files (.apk or .ipa) can be altered and published in different markets by hackers. They may inject malicious code in your app or they may crack mobile apps to bypass license and payment restrictions. Nowadays it’s even possible to crack in-app purchases and license checks just by emulating app store responses. Therefore, application integrity and in-app purchases should be checked with a third-party trusted server to prevent such cases. For this purpose, there are some good solutions available in the market. Again, this is very critical for Google Play and iTunes App Store security.

app_security

If you are developing your app with a Platform-Based Approach (Obj-C, Swift, Java) the items above should be managed entirely by yourself or your team. However, if you’re using a cross-platform native framework approach, most of the items above are covered by the mobile development framework for mobile app security.

We especially suggest you to use cross-platform native frameworks for mobile security industry. You may have already faced the well-known risks of cross-platform hybrid frameworks, such as DOM Payload, Scripting Engine Scope, etc. You can assess security capabilities of the Smartface.

(collected from Smartface)