Back in 2007, Apple launched the iPhone and created a whole new way of developing software: apps. Before apps, most development relied on a full stack of a UI tied closely to code that pulled content from databases. You secured the entire stack, and the idea of separating your security concerns was not only unheard of, but also pretty much impossible to achieve.

Apps were different — the UI became a much more lightweight, portable component. The data itself was moved to an API – an application programming interface – which allows the application to, well, interface with the backend data without a lot of JDBC or (shudder) ActiveX connections. The data is now available over https, just another asset like images or style sheets.

But how do you secure that data? It became clear that Basic Auth (a username and a password) wasn’t going to do the job. The first APIs left it up to the app to limit what user saw what data, but hackers quickly found that they could get to an entire data ecosystem pretty quickly, and the idea of RBAC and fine-grained access started to filter up through the development world.

Suddenly, a whole new industry cropped up for API security. New protocols started showing up — new services like API gateways and new ways of organizing data like REST became standard.

But the evolution continues. We’re slicing our systems into smaller and smaller microservices. The laws are changing and so is the way the users of these apps think about data. So let’s take a look at how folks secure APIs and the pros and cons of their security approaches.

Let Your App Do It

As an API guy, I hate to think there are still application stacks out there that are responsible for their own security, but there are. This could be simple Basic Auth, or a “Client Credentials” OAuth. The idea is that the app has full access to the entire API, trusting the app to give the right data to the right user.

This is fine as long as the app isn’t compromised, but the moment a bad actor gets a hold of the keys the app uses, it’s all over. That bad actor can read anything, create new things, and, depending on the capability of the app, the bad actor can delete things. A common ransom technique is to grab a copy of the data, delete everything, and then create a record or two that gives instructions on how to pay to get your data back.

App + User Level Access

A better model is to tie your security policies to what the app is allowed to do, and then further restrict it by what the user is allowed to do. The app can’t generate a token without a user, and that token is then tied specifically to the user’s permissions.

This means that if a bad actor starts poking around, the only data they should be able to mess with is their own. If you include things like rate limits on access – only having the ability to watch one movie at a time on Netflix, for example – then the API should see if the user is trying to download 50 movies at once and stop them. And one would hope the API is smart enough to revoke the user’s access until it receives identity verification like a multi-factor verification (e.g. a text message with a re-activation number that forces a password change).

App + User + Device Level Access

We know that data gets copied every time someone looks at it. When dealing with really sensitive data – medical or financial data or a company’s intellectual property – you may not want your authorized user with a verified app to use an unverified device like a personal tablet or PC.

Many attack vectors are about stealing access keys and then using anonymous cloud tools to pull the data to an outside location. The “grab/delete/ransom” model doesn’t usually happen from an iPhone. But now there’s a new vector: installing malware on the app’s device and grabbing data from the device.

In that case, your app and your API may still be secure, but any data your user is viewing may still be compromised because the device can’t be trusted.

App + User + Device + Microservice Access

And now we get to the East/West traffic issue… Your user uses an app on a trusted device to call to an API, and all is good. That “API,” however, is just the interface between your application and your backend services. What happens if your backend service is compromised?

Say I look up a person by doing a GET /people/michael.bissell — that service may be doing some orchestration on the backend to look up my company details by doing its own GET /organizations/cloudentity. Now, I shouldn’t have access to do a GET /organizations/IBM because I don’t work for IBM. Unless we create rules to limit the microservice communication there’s nothing stopping that “people” service from rummaging through the “organization” service all day long.

We can’t trust our microservices any more than we can trust our iPhone apps. CI/CD practices, polymorphism in our code, and just the constant barrage of attacks means that backend services need to be treated with just as much skepticism as our front-end code.

To answer the question, “What is the best security model for my API ecosystem?” I feel the answer has to always be, “Trust no one. Secure everything.”