API security methods developers should use

All companies use APIs to connect services and applications. If not properly secured, attackers can use them as entry points for injection, denial-of-service and hijacking attacks.

API security needs to start being addressed during the development process. To help developers understand what security features to include, ForgeRock Security Director and author Neil Madden wrote API Security in Action. He said it's important for developers to consider security when creating APIs, but there is a general lack of content around API security at the moment.

"It's the book I'd want to buy right now," Madden said. "We need to adapt our existing security knowledge to protect APIs."

Check out an excerpt from Chapter 3 of API Security in Action, which breaks down how to add security and authentication features to APIs in development.

Here, Madden talks about why he focused on developers, the importance of OAuth 2.0, recommendations for adding security features to older APIs and more.

Editor's note: The following interview was edited for clarity and length.

Why did you decide to focus API Security in Action on developers?

Neil Madden: My philosophy is that security is very much in the details. In application security, you can apply a lot of controls externally to the application itself, but if your developers aren't writing with security in mind, they can introduce weaknesses into any well-defended external controls. I want to reach developers and embed that knowledge of security directly for them. That's the most effective way in the long term to improve security across the industry.

Learn more about Neil Madden's
API Security in Action here.

While the book has a dev focus, there are also things infosec professionals can learn. Some chapters they could skim, but others cover important topics, such as OAuth 2.0 and Kubernetes. There are some aspects of security that overlap with business logic as well, such as authorization. I didn't want to leave that out and only focus on rate limiting and JSON [JavaScript Object Notation] web tokens and external security.

Which chapter should readers pay the most attention to?

Madden: Chapter 7 on OAuth 2.0. I'm part of the OAuth 2.0 working group at the IETF [Internet Engineering Task Force], working on the new specifications. OAuth 2.0 is one of the most important technologies for APIs right now and maybe even the most misunderstood.

OAuth 2.0 aims to solve the problem of delegated authorization. The original example is LinkedIn contacts. The original way you got LinkedIn contacts was to give LinkedIn your email address and password. It would then log on as you and read your contacts. With OAuth 2.0, we're saying maybe you trust LinkedIn, but should all services be given similar permissions? Anyone can connect and do anything as you with your email account. With OAuth 2.0, the site gets a restricted access token that says exactly which parts of your email service can be accessed, such as read-only access to contacts.

OAuth 2.0's design flows from the idea that you as a user have access to your email, and that access is limited so you can't read somebody else's email. A lot of people try to use OAuth 2.0 as a complete replacement for all of their authorization. They end up with security vulnerabilities where they use scope [limits application access to user accounts] to control access, but that's not enough. Going back to LinkedIn, you've given it read-only access to contacts, but because you're not checking any other authorization, what you're actually giving LinkedIn is read-only access to everyone's contacts. You're no longer checking who is who and thus creating a vulnerability.

This could then introduce direct object vulnerabilities where LinkedIn is sent a URL to read messages, for example, but it can be tweaked to access someone else's account -- for example, /messages/Kyle to /messages/Neil. Then, nothing checks that Kyle shouldn't be able to access Neil's messages. This kind of vulnerability happens when people try to use scopes as a complete replacement for all permissions in their systems. In the book, I talk about the difference between scopes and permissions and how you usually want to have both.

How difficult is it for developers to add security features from this book to existing APIs?

Madden: It depends. For a lot of features, like verification, it's not hard to add them on top. We're seeing more and more gateway products, which layer technologies on top.

The most difficult part is authorization. Once you've worked out who the user is -- which can be offloaded to a certain degree, along with rate limiting -- the core decision should be whether the request is allowed or not. Some companies, mine included, offer a policy engine for authorization decisions that you can call out to. But the issue is whether you should separate authorization from logic.

That's a tricky thing to tackle. Developers often made specific assumptions about how older APIs and other technology were going to be used. This can make it harder to add new things on top.

What should devs do with older APIs that can't be retrofitted?

Madden: The best first step is to put a gateway in front or use a reverse proxy, such as Nginx. Start applying more security rules from there. Next, make sure to block all APIs that shouldn't still be in use. Things like that will go a long way to reducing your attack surface. If possible, add logging and other features for better visibility into the traffic to your APIs. From there, start playing with more advanced gateway features. Have gateways in place before you start rewriting your APIs behind the scenes.

Is there anything developers often overlook when tasked with adding security to APIs?

Madden: OWASP's [Open Web Application Security Project] Top 10 API security vulnerabilities is on the money, especially with number one -- broken object level authorization. I refer to it as 'insecure direct object references,' which basically is whether you're checking if someone should have access to a specific object. Is it supposed to be in their inbox or someone else's? Do they have access to this specific document? This is a really common vulnerability where people think that, if you've accessed a particular URI [Uniform Resource Identifier] and that if you have access to that URI, that that's enough. Developers often don't think about what happens if the users change the URI to point to a different document or user. Can users then access a different document or inbox? Devs aren't always applying checks at the right level to prevent that.

What is the toughest aspect of securing APIs for devs?

Madden: There are a lot -- there are even things that should be easy that end up being difficult. For example, anything using JSON web tokens is tougher than it should be. There are a lot of pitfalls, especially since a lot of the current libraries aren't brilliant at hiding those pitfalls for users, though they are improving.

While that's accidentally hard, authorization is the hardest issue. Who has access to what? It's tricky because there's no one-size-fits-all answer. It depends on what your API is doing, who the users are, what things are going to get accessed, etc. You really need to sit down and think about that. There are a lot of tools that warn about security vulnerabilities, but authorization is much more difficult. You may have a spec that will detect when you're not applying authorization that should be. But coming up with that spec of what authorization should be there in the first place is often quite difficult to figure out.

About the author
Neil Madden is security director at ForgeRock and has an in-depth knowledge of applied cryptography, application security and current API security technologies. He has worked as a programmer for 20 years and holds a Ph.D. in computer science.