When you think of API security, you typically think about your own APIs. So you’ll make sure you’re using proper authentication and authorization on your web services. Then you’ll verify you’re using secure coding practices. And then you’ll even add monitoring and alerting for anything out of the ordinary. Because you know that securing your application is critical for both you and your customers.
But what about external APIs that you use? Should you worry about the security of their providers? And are you vulnerable using third-party interfaces that provide needed functionality?
In short, yes, you should worry about other APIs because you might be vulnerable due to a provider’s poor security practices.
Whether external calls to other systems or dependent system libraries, you need awareness of security around those API calls—because it’s not just your own vulnerabilities you need to watch out for. In addition to our own vulnerabilities, we need to watch out for the security of APIs that we use. In this post, we’ll take a look at what we should consider when evaluating an API’s security and some of the steps we should take to protect ourselves.
Let’s start with a brief look at APIs.
What Is an API?
When we break it down, an API, or application programming interface, is just a way for one process to talk to another. APIs can take on many forms. For the common example, when you call a remote server with an HTTP or WS request, you’re using an API. Or if you access the operating system on your server using the Microsoft Windows API or something similar, you’re also using an API.
More and more helpful APIs exist for software development and general productivity. Some, like the Slack API, help us collaborate with our teams. Others, like Google Maps, allow us to provide functionality for our customers with little work on our part. And even further, our cloud providers allow us to use APIs to deploy our applications and manage our infrastructure.
But what security risks do we take on when using these APIs?
Why Worry About Other APIs?
Reports show that most applications consist of 90% external dependencies and libraries. And although our own code typically has more security flaws than hardened and maintained external APIs, we still need to be aware of the risks. Because using dependencies and APIs can lead to vulnerabilities, that 90% just added a large attack surface area to our application.
Let’s consider another issue. Sometimes dependencies can expose APIs that you’re not aware of. If you’re not completely familiar with the systems you integrate with, you could open your application up to risks just by not reading the fine print.
Now, some of you may feel secure knowing that the third-party APIs you call are open sourced. With more eyes on the code, how could there be blatant security flaws?
Well, let’s remember that just because something is open source doesn’t mean that vulnerabilities have been eradicated. For example, the Shellshock vulnerability existed in OpenSSL for 22 years. And no one caught it in all that time!
So remember, even though some open-source projects have a great deal of scrutiny, they aren’t impervious to security issues.
What Should We Look for Before Using Other APIs?
Before incorporating new APIs into our application platform, we should consider a few things. In this section, I’ll cover a few things specific to different types of APIs as well as general advice for all APIs.
For third-party APIs that are hosted on external servers, make sure they use HTTPS/SSL. And be wary of APIs that don’t require authentication or developer tokens. API providers give keys to keep developers and users of the API accountable for malicious attacks. In general, you want all APIs to take as much care as you would with proper authentication, authorization, federation, and delegation.
Many APIs can plug in to your browser. And unfortunately, we can’t always control what our customers do. But education can provide coverage. Make sure your customers understand the risk of adding browser plugins. If you’re in an enterprise environment, lock down the ability to add any unknown plugins.
Browser APIs can be helpful, but they can also steal your data, access your active login sessions, and access various online accounts. They can also download files and store them on your device.
Don’t take for granted that data security can fall apart at the browser or device level.
With so much of the heavy lifting being done by our cloud providers, we may forget that some solutions may invite security flaws to our application environment. For example, you may have inadvertently created an EC2 instance with an insecure IP address. Or perhaps one of your S3 buckets needs proper protection.
When using cloud providers to manage your infrastructure and platform, don’t assume they’ll keep you safe. You need to provide your own due diligence and learn about the potential security flaws you can introduce through configuration.
Whether external APIs, libraries hosted on your server, third-party applications, or OS APIs, we should investigate a few things.
For one, read the API documentation. If an API provider doesn’t maintain up-to-date and extensive documentation, they might not maintain their security either.
Also, if the API’s documentation doesn’t mention your specific security concerns, ask them. If you don’t understand the risks, ask them about that too. Find out if they store data in an encrypted format. See if they replicate data between production and test environments or if they keep data (and access to the data) properly segmented.
Overall, learn about what your API does and, to some extent, how it works.
How Do I Protect My Service From Attacks on Third-Party APIs?
OK, so we’re using all sorts of APIs. We have to. It’s how we get the job done. So how do we protect ourselves?
If your third-party APIs succumb to a DDoS attack or other issues, you may reduce the availability of your application. Because of that, you should consider caching data from third-party APIs to ensure you don’t lose functionality when they experience reliability issues.
Additionally, consider using the circuit breaker pattern in order to not continuously retry connecting to a system that can’t respond, making the situation worse.
When monitoring your application, look at ways you can also add monitoring on your usage of APIs. Then, if a high percentage of requests starts failing, you can investigate further. Additionally, add contract tests to validate that your provider’s API hasn’t changed without your knowledge. Or if unexpected traffic starts going to one of your dependencies, you’ll want to take a look at what’s going on.
And finally, whatever APIs you use, one important factor that keeps you safe involves frequent upgrades. Make sure you and your team are ready to update to the latest version of dependencies when a security flaw gets fixed. The longer you use outdated and vulnerable APIs, the more you’re putting yourself and your customers at risk.
When considering security concerns, we must stay vigilant and aware. And we can’t take security for granted, assuming that third-party providers take care of everything for us. Ultimately, we’re all responsible for our own application security, and that includes all the dependencies we use.
All of this can seem overwhelming. However, remember that you don’t have to work through all of this alone. Staying knowledgeable about security takes time and effort. And it requires expertise and advice from professionals. Carve Systems can help take you to the next level. Consider some of their offerings so that you can feel more confident in your security choices.
Author: Sylvia Fronczak