10 Mobile Security Vulnerabilities and How to Address Them

Developers need to be aware of the most prevalent mobile security vulnerabilities and the best ways to handle them.

API services on the Web are accessible even without the mobile app for which they were created. Hackers can sniff out the wireless network or perform a man-in-the-middle attack to discover the API calls being made in order to modify them and attack the API directly. How to address it: Secure coding and configuration practices must be used on the server side of the mobile application; specifically, the API should securely verify the identity and permission of the caller.

Development teams assume that users or malware will not have access to the file system of the mobile device where sensitive information is stored. How to address it: If possible, do not store any sensitive data on the device or inside the mobile source code, and if the business requirements call for storing sensitive information on the mobile device, then use encryption above and beyond what is offered by the mobile OS.

It’s a common misconception that if you use SSL/TLS in your mobile app, then it is secure. How to address: Use certificate pinning or HTTP public key pinning (HPKP) to prevent man-in-the-middle attacks or two-way authentication to gain non-repudiation and authentication capability of both the server and client. Make sure that all connections to your servers are encrypted (if applicable) using best practice configurations (i.e. currently TLS 1.2). Do not accept user-accepted certificates as authorities, and make sure your SSL certificates are up-to-date and signed by a trusted certificate authority.

The focus on protecting data often considers the typical mobile app use cases and attempts to protect data from that point-of-view. The truth is that there are a lot of other ways your data gets viewed, copied, cached, screen captured, backed-up and logged. How to address: Consider that a native mobile operating system often provides ways for users to copy/paste data, take screen captures, create mobile data backups, use custom keyboards and collect analytics with third-party apps. Consider the data and risk presented by these scenarios and determine if it is acceptable in your mobile app. If not, then you must explicitly prevent these capabilities from within the mobile application or through control of the device with a mobile-device management or mobile-application management (MDM or MAM) solution.

Even if a mobile app user authenticated once, his/her credentials could easily be stolen from an insecure wireless network. Never assume that just because a user has been authenticated that he/she is automatically authorized to do anything at any time. How to address: Authenticate and re-authenticate users periodically, and before any sensitive action is performed. Authorize every request every time.

The mobile app may implement or use an encryption/ decryption algorithm that is weak in nature and can be directly decrypted by the adversary because the implementation architected by the developers is fundamentally flawed or there are poor key management processes. How to address: Ensure that your crypto implementations are reviewed by knowledgeable security professionals.

A common misconception is that a mobile app cannot be modified by malware (for example, libraries replaced or code injected into the app by malware). How to address: Harden the app to protect against tampering both statically and at runtime. Perform input validation in the app and the APIs, perform integrity checks on sensitive information, and be careful how you use WebViews because they can result in vulnerabilities such as Cross-Site Scripting (XSS).

Hidden fields, IPC (inter-process communications) calls and Web service calls cannot be trusted, since all of these can be easily manipulated with the right tool. How to address: Never assume these sources of data can be trusted and properly protect them against tampering and abuse, including implementing authentication, authorization, integrity checks, encryption or other mechanisms.

Attackers can use session credentials to authenticate to the back-end service and perform actions as a particular user. How to address: Implement a timeout mechanism for the session cookie on both the server and the client. Generally, the recommendation is for one hour or less. Ensure that your server establishes a new session for each user every time authentication is required. Make sure that old sessions are destroyed/invalidated on the server to prevent reuse.

Your mobile app can be at risk of being reverse-engineered, analyzed or tampered with. How to address: Protection varies by threat and mobile platform, but you will want to make sure that your application is protected at runtime against analysis, monitoring and code injection, and that the source code is encrypted and obfuscated. Integrity checks can help prevent modification of resources and source code.