The use of mobile application on consumer grade devices is increasing in popularity as more and more companies are using customised apps on mobile devices for field purposes instead of using a purpose built device. Example of such an implementation can range from Biometrics Scanning, Merchandise Delivery or even Taxi Dispatching.
Certain risks are associated with this approach since unlike web applications each user is responsible for managing and updating his version, just like the pre web-apps days back when people used desktop applications, These risks include:
- Using an obsolete version of the app that is no longer compatible with the backend.
- Using a version of the app that include a critical security issue.
- Incorrect business process due to the use of an older version of the app.
- Using a none official version of the app using the same backend, thus bypassing any front end validations.
There are certain guidelines that can be followed to control the inherent risk, I’m going to list some of them here as a guideline
I. Upgrade Enforcement
For critical upgrades that renders the previous versions obsolete, for instance changing the business process or introducing a critical security enhancement. The best practice is to break the backends backward compatibility.
Breaking the backend backward compatibility can be done by adding an app version check with every request, including the app version in every request is easy and has a negligible cost on both data and processing yet is very useful when needed. The server response should include an error code that would trigger a “You Must Upgrade Now” message.
II. Upgrade Notification
For less critical updates push notifications can be used to suggest an upgrade to the customer, a more aggressive approach (for android) would be to handle the push to fire the play store on the application’s URI. The frequency of these notifications can reflect how important this update is.
III. Application Verification
To restrict against none official apps the api should include a verification token, there are many ways to implement this, one of the easiest way would be encrypting one of the fields (timestamp for instance) and sending both the encrypted as well as the none encrypted versions. The backend would then verify the version of the app by comparing the decrypted field against the plain text one, if they do not match the response should indicate that.
There are many ways to implement this, the encrypted field approach happens to be the easiest way to do it.
IV. Root Check/Emulator Check
Rooted phones can offer a malicious user the means to manipulate the backend calls, while keeping the verification field. A root check can be conducted on the device every time an activity is started. Emulators are easy to uncover as well.
V. Malicious Usage checks
Just in case all of your checks fail, backend should conduct even a rudimentary malicious behaviour check, blocking devices that exhibit none expected behaviour.
VI. Connectivity Issues
Even with the advances in cellular service coverage 3G/4G service remains spotty especially in rural areas. There are few ways to mitigate this depending on the nature of the requirements. If no online/sync operations are required you can implement a simple request cashing service, in which server side requests are cashed to be retried when connectivity is available.
VII. Usage Patterns Analytics (for android)
Creating usage heat maps is important when it comes to determining how the people are actually using the applications and whether certain features should be augmented or removed due to lack of usage. Luckily google analytics can be integrated to track usage or activity launches, it can even be used to track individual controls actions.
I hope this post was helpful I’m planning to write another post soon on how to conduct unit, QA and scale tests on enterprise apps.