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 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.
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 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.
There’s no easy button for securing an API
To me, this e-book from Contrast Security, a maker of web app scanning tools, is telling. It’s 20 pages long, but I can summarize it in about three sentences. They tell you to implement secure coding practices. They tell you to perform manual tests. And they don’t try to sell you anything.
As someone who’s worked for three security vendors, when a vendor doesn’t try to sell you anything, you need to pay attention. Their first job is to sell you something. Their second job is to make you successful. If a specialist in this space is giving you tips on being successful without trying to sell you something, that means they don’t have a tool they can sell you that will make you successful. Their job is to make easy buttons, and they haven’t been able to make one.
I know some people will have cynical takes on this, but security vendors really do care about their customers’ success. At least the good ones do. Back in 2018 or 2019 when I worked at an MSSP, someone from Tenable stopped and talked to the CEO of my former employer at RSA. They recognized the company logo and asked him if he knew me. Then they told him that I really give them a hard time sometimes. He asked if he needed to have a conversation with me about that. They said no, I was hard on them because I wanted our mutual customers to be successful and they want the same thing, so they appreciated me keeping them honest.
So how do you secure an API, according to the experts? You implement secure coding practices as early in the SDLC as you can, and you perform manual tests.
And to cover the shortcomings of those two things, you limit access, filter, log, and encrypt.