A former coworker called me up the other day. He interviewed for a job and they asked him how to secure an API. Which reminded me of the many times people asked me how to scan an API with Qualys when I worked at Qualys. You’re certainly not going to give a complete answer in a job interview, and I’m not sure I can do much besides send you down the right path, but there are certainly some wrong answers to this. So let’s talk about how you secure an API.
What are you looking for?
The problem with securing APIs is that people tend to look at the wrong tool. Both when it comes to the tools they have, and the tools they need to buy.
The first thing is to make sure you’re asking the right questions. I had one customer when I worked at Qualys who told me he wanted to scan APIs and load balancers with the Qualys WAS product to “find buffer overflows.”
I don’t want to sound like a snob, but if you don’t see the problem with that statement, you’re not an expert in vulnerability management. You have to use the right tool for the job, and in this case, that’s two different jobs and Qualys WAS circa 2016 wasn’t the right tool for either of those.
There is a perception that vulnerability management tools are all interchangeable and they aren’t. Just like you can’t go to the hardware store and buy one hand tool and one power tool and be able to expect to build or fix everything around your house, you can’t expect one or two vulnerability management tools to do everything either.
There are automated tools for APIs, but the web application security product from the big three vulnerability scanners aren’t it. Part of the solution is in the tools you already have, but make sure you’re looking in the right place.
Start with the basics to secure an API
The first place to start with this question is with the basics. Do you limit access to the API, requiring some type of authentication? Are you able to limit access to the API to certain IP ranges? Are you able to use permissions to limit what calls some users can make? And does your API log what calls people are making, who made the call, when, and from where?
I ask that because you’re not going to think of everything, but if you’re at least doing authentication and logging and limiting access, that covers a lot of problems. You can’t trust everyone. But it’s easier to limit access to people you trust than it is to build something that protects itself from people you don’t trust.
Next, is the network secure? You need to be using HTTPS, but are you using current standards for HTTPS? What was good enough for 1997 isn’t good enough now. When running vulnerability management programs for large enterprises, I frequently got pushback on updating HTTPS because they didn’t know what would break. That points back to logging. If you know what’s connecting to your API, then you know what TLS versions and ciphers they support. You don’t need to worry about Java 6 if nobody is connecting to your API with Java 6.
The other question is where your API sits on your network. Sometimes it has to be public facing. But if it doesn’t have to be, keep it internal. If you can put it in a DMZ or your internal network, put it there. The more you can isolate it, the more faults you can cover.
Firewalls!
Firewalls fix everything, right? Nice try. You can use a network-based firewall to limit access from sketchy IP ranges, and you can use a web application firewall to filter out known attacks. They both help. Neither of them are 100% effective. That doesn’t mean they aren’t worth doing, but you need to be aware of their limits.
Why you can’t secure an API with just a scanning tool
While it’s sometimes possible to scan an API for vulnerabilities the same way you would scan a server operating system or a web application, it’s tricky. The web app scanning products from Qualys and Tenable are designed to scan web applications, not APIs. Just because they both operate on port 443 doesn’t mean one product can handle both use cases well.
They’ve gotten better about scanning APIs from what I understand, but they still don’t always work. And when they do, they’re prone to false positives and false negatives. If you’ve ever written a Python program that calls an API, you can start to understand the problem. One character can make all the difference between an API call working and returning data, or throwing an error message. There have been times I spent half the day figuring out how to get a single API call just right. How is a scanning tool supposed to account for that? It won’t. It will do the best it can and move on to the next API endpoint it can find. And that means it will miss things.
The closest thing to an easy button for securing an API
To finish the job, you need a specialized DAST tool. The only automated DAST tool that I am aware of at the moment is a tool called APIsec. They are still a young company but have a good pedigree. You’ll need to do a proof of concept to see how it responds to your API of course. But at least someone is looking at trying to solve that part of the problem.
Eventually, more generic tools may start expanding into this space, but for now, specialized tools are the way to go. Finding the code to fix the problems they find and implementing secure coding practices is still on you of course. But at least there’s an automated way to find the problem now.
So how do you secure an API, according to the experts? You implement secure coding practices as early in the SDLC as you can, scan with a tool specialized to the job at hand, and perform manual tests as necessary.
And to cover the rest of your bases, you limit access, filter, log, and encrypt.