In the final part of this four part series, we’ll recommend what actions you should take and when you should take them in order to implement effective shielding of your mobile app and APIs it uses.
In part 1 we looked at the threats to APIs and mobile apps; in part 2 we looked at the active attack surfaces which are available to hackers in a mobile-centric platform; and in part 3 we examined some methods you could employ to defend your platform against attacks of various kinds.
Here is a refresher of some of the main observations from the previous articles in the series:
- Protecting a business that relies on mobile apps to interact with its customers requires end-to-end security because there are multiple attack surfaces at play.
- Defending against API vulnerabilities is not enough on its own; protection against API abuse via scripts which do *not* exploit vulnerabilities must also be deployed.
- Ensuring that only genuine instances of your mobile app can use your API isolates your mobile business from both API abuse and API vulnerability exploitation.
So what should your approach be to protecting a mobile first business and in what order should you take the necessary steps? It’s tempting to focus first on finding vulnerabilities in your APIs so that you can remove them and sleep better at night. However, getting a basic shield in place first should be your immediate priority.
We would propose the following steps, in priority order, to be started right away:
- Implement a shield for your mobile app and its APIs. In this context a shield is something that can protect your data at rest and/or in transit against leakage and exploitation at scale.
- Implement the security basics in your mobile platform if they are not already in place, i.e. mobile app code obfuscation and certificate pinning.
- Implement a regular pentesting program, utilizing external resources to seek out vulnerabilities and verify resilience against abuses of your APIs.
- Implement a plan, based on the pentesting results, to correct the vulnerabilities in your API and adopt a secure-by-design development methodology to reduce the risk of introducing future vulnerabilities.
We hope that you have found this blog series informative and useful. If anything is unclear, you would like to ask a question or if you would like to talk to one of our mobile app/API security experts, please get in touch.