Barry O'Rourke
When retrofitting an API change to an app which already has an existing install base care must be taken to handle the transition with minimal disruption to customers.
Much has been written about how to implement API versioning and changes with a focus on not breaking the API and ensuring that all clients accessing the API before a change can carry on afterwards. But what if the point of the change is to actually block those accesses?
Deploying Approov provides a straightforward method to integrate robust attestation into your mobile app. An attested app will be able to present your API with a token in the header of every request as proof of its validity. This allows you to filter incoming API requests to block unattested traffic, providing a simple way to block unwanted accesses from bots and other 3rd parties.
The initial roll out of this capability can be approached in a number of ways depending upon your goals and the existing capabilities of already deployed apps.
Request Blocking
The obvious approach to implementing API access control is to deny any request which is unattested with the API returning a suitable status code (Bot and Aold in the example below). Typically this would be a 400 (Bad Request) or a 403 (Forbidden) but you should tailor this to suit your client app, so if you have a custom 2xx response for exceptions for example, you should use that instead.
Since we are talking about potentially denying functionality to legitimate users then providing a meaningful message body in the response urging them to update is a must, assuming that the app implementation supports the display of such a message.
Just Go For It
The simplest way to deploy blocking is to enable token checking on the gateway to your API a few days after pushing your app update with attestation enabled. In this scenario you are relying on the vast majority of your user base to have auto updating enabled, which is likely, and to be regularly connected to a wireless network, again this is likely to be the case. The small percentage of users who have not updated will find that your app has stopped working which is not good even if it is rare.
Fact Based
By logging the number of API requests with and without valid tokens it is possible to measure the propagation of the update through the install base. More importantly, this will tell you how many active users have updated, allowing you to make an informed decision about when to switch off support for unattested API requests.
Typically you wait until the rate of attested requests has stabilized before blocking access for the rest. Alternatively you may have a particular threshold which is acceptable from a business perspective that may take longer to achieve.
Filtering Proxy
Simply blocking results in a very simple implementation for the token checker is unlikely to meet your needs if you want users of legacy apps to have a soft landing. An alternative is to apply filtering in the token checker which is acting as a reverse proxy for the API.
In this scenario unattested traffic still reaches the backend services but the request is modified and potentially re-routed, based upon the token check result, to provide a reduced service.
Rate Limiting
For many businesses, automated bot traffic is an issue due to the rate transactions are issued. Once this traffic can be identified by failing a token check, the transactions can then be rate limited using any one of the many solutions available. This benefits app users who have upgraded by providing them with fast track access to the API, and it reduces the impact of bots on the user experience of the service. For example, in an online game people using automation would lose their unfair advantage.
The downside is that a non-updated user of the old app version will likely see a degraded service. However this will act as a prompt to seek to upgrade, especially when combined with in app promotion of the upgrade when possible.
API Subsetting
Since the addition of Approov attestation takes place in the context of an upgrade to an app, it is likely that more features will also be added at the same time and certainly as the app develops further overtime. As this occurs it is likely that the API for the backend will be extended also to support the new features and my even be completely overhauled.
In this scenario unattested traffic is routed to the old API which is frozen. This means that API scraping bots, for example, will not be able to reach new, potentially more valuable, data. A more extreme version, if applicable, is to deprecate the service behind the original API potentially making it almost static. This will gradually reduce the value of the data making it less attractive to bot developers and again providing a prompt to the last few legitimate users to upgrade.
Wrapping Up
We have sketched out several approaches to managing the transition to an attested API and hopefully some of these ideas will map onto your business and allow you to improve your API security. Ultimately there is going to be some disruption to a small number of customers who for whatever reason do not receive an automatic update to your app, and it is important that this is carefully considered as part of an Approov deployment. Hopefully this article will help you develop an effective strategy for locking down your API to the benefit of all your users.
