APIs are everywhere, and their security is becoming challenging.
Gartner is seeing explosive growth of APIs and estimates that by 2025 less than 50% of enterprise APIs will be managed; the companies just don’t have the capacity to do it. So, API security is becoming a crucial topic.
It goes without saying that APIs are deployed everywhere. For instance, a website click quickly initiates a dozen REST calls directly from your browser and another dozen behind the scenes. Software engineers like you integrate with APIs more and more to develop new features and enhancements.
Are you able to secure your company’s API sprawl?
As software engineers, we can divide APIs into two kinds: those we build & maintain ourselves (the homegrown); and those we consume (the 3rd-party externals). In this webinar, TeejLab Founder & CEO Dr. Baljeet Malhotra and MergeBase CTO Julius Musseau talked about API risks, API governance, and best practices for software engineers building and consuming APIs.
They covered the following topics:
- Why it’s essential to think about risk when building APIs
- How to protect your company from the potential damage caused by a compromised API
- API Security best practices and standards
Why Do APIs Matter?
- The “REST Revolution” gave us all an important software architecture for free: front-end/back-end.
- And then back-ends started calling back-ends.
- And the rest is history!
What do we need to do?
APIs act as translators that allow communication between various devices and/or apps.
APIs must be: Discovered, secured, and governed systematically.
The overall ecosystem of APIs at the global scale is already into millions of public APIs. We have indexed a lot of them that way, and we have built the world’s largest repository of APIs, more than what programmable web has, more than what rapid API has, or even that other organizations may have catalogued.
- Microsoft in 2020: 60,000
- Google: 35,000
- Amazon: 30,000
How do you discover APIs?
It is a technologically challenging problem. It is a very easy concept to understand but very hard to solve because the information over the internet could be so unstructured.
There is a lot of unstructured information available on the internet, and a lot of this information is embedded in the software liability itself because a lot of times, a lot of companies have APIs, but they never published a report or a portal or a page which describes their APIs simply because either they don’t have a business functionality, they want to expose, or they just want to keep these APIs secrets for just their customers and partners.
There are various mechanisms we are applying that are curating this information at a global scale, mining repositories mining international web pages.
It is possible to get visibility into authenticated APIs?
Yes, because if you just see the declaration of an endpoint that isn’t good enough, that doesn’t tell you what that API actually does. So, if we wanted to go beyond that, we need to authenticate and access the API, and many times you need to register to get the account, get the API keys, or in some cases, the authentication can be author or JWT.
So we could use these APIs as much as we could, but there’s a lot of automation that can’t be done because you actually have to register to get the key.
And to do that, we need to have information where we can actually authenticate and make a call to the API and actually see what data comes in and out, look at the header, look at the response and other information so that there are authenticated APIs in your index absolutely no interest, that’s what makes things more interesting.
How can you secure public APIs?
Simple things, for example, you may create an account to access an API, do some experimentation and may end up not using it, but it can stay there; you may forget maybe you might hardcore the password because you were in an experimental shooting mode and suddenly you checked out this library and somebody decided to make this open source. There you go, you expose some of those things.
The first step is to be aware of all your APIs, document them, and nicely catalogue them. Because the problem is a lot of times, teams do not know their APIs and end up being exposed to unnecessary risks.