API Security: More Than Just Apps

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 pretty much impossible to achieve.

But apps were different — the UI became a much lighter weight, portable component. The data itself was moved to an API — an Application Programming Interface 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 to 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, and because of changing laws and the way  users think about data are changing. So, let's take a look at how folks secure APIs, as well as the pros and cons.

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, the app is trusted to filter and only give the right data to the 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 all over. That bad actor can read anything, create new things, and, if you let the app delete things, 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 where to pay to get your data back).

App + User Level Access

A better model is to tie your security policies to both what the app is allowed to do and 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 he should be able to mess with is his own. If you include things like rate limits on access (say you're Netflix and you can only watch one movie at a time), 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 some verification like a multi-factor verification (e.g. text message with a re-activation number and force 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, financial or company 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, there's a new vector — installing malware on the app's device and grabbing data from the device.

In that case, your app and  API might 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 — now 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 the 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."