Many APIs are openly accessible online, and that means big chunks of your apps are, too. Cisco’s Vijoy Pandey has tools and tips to help businesses get visibility into their APIs.
There’s a slight problem in the world of app development, and it’s one that’s pretty fundamental to the way modern software works: The disconnect between the necessity of application programming interfaces (APIs) and their horrible reputation as security black holes.
This isn’t a new problem — we’ve known APIs were an issue for some time, and now we’re at a point where 91% of enterprise professionals said they experienced an API security incident in 2020.
APIs are responsible for taking some of the most valuable data that an organization uses and sending that data, when requested, to another application using the API to decode that data in a way the app can understand and return to its user. Think of a social media app: That data isn’t just appearing by magic on your phone, it’s a Twitter API that’s taking the data constituting your feed and sending it to the Twitter app.
Here’s the problem: APIs are by their necessity publicly available. All the big companies that rely on app developers, be they internal or external, have APIs available that can pull incredibly sensitive information.
Apps that make heavy use of APIs are, therefore, leaving a significant portion of their code available publicly online, says Cisco VP for cloud and distributed systems, Vijoy Pandey.
“You might be pulling APIs from the public cloud, SaaS providers, Salesforce or you may have on-prem APIs that you’ve created in a monolithic environment like a Java app. Or, you might have them running as a microservice or in a serverless manner. It doesn’t matter how, but you’re using APIs … so your application is really sitting on the wide open internet,” Pandey said.
Cisco introduced a new open-source software tool called APIClarity to address what Pandey described as “a plethora of problems” surrounding API visibility.
“Many people don’t even know what an API is, or how they’re being used by developers. They don’t know which APIs are undocumented, which are depreciated and still being used and many developers don’t take the time to document their own APIs, or update documentation to account for API drift,” Pandey said.
APIClarity’s goal is to eliminate the security risks that come along with API visibility issues, and it does that by listening to API traffic and using the data it collects to create an OpenAPI specification for it. That’s just step one, Pandey said.
“Once you have an OpenAPI spec, you can see what an API is actually transmitting, versus what it was originally intended to do. Say you intended it to pass an integer, but over time people started sending flops. Or you intended two arguments, but over time people started passing three or four, and the API spec hasn’t been updated. These are clear attack vectors,” Pandey said.
Pandey also pointed out that an APIClarity spec enables penetration and fuzz testing of APIs, puts developers and security teams on the same page, and he hinted that Cisco has other projects in the pipeline that “will further leverage APIClarity to provide users with additional capabilities.”
APIClarity is open source and available on GitHub, and Pandey said that it’s designed to be installed frictionlessly in any cloud-native environment. He describes it as a runtime tool that Cisco developed to avoid having to tell users to install another agent. “We are ultimately trying to cover the visibility of API traffic in your environment in its entirety, and APIClarity is the first tool of its kind that does this,” Pandey said.
It takes more than just identifying holes in, and sanitizing, your APIs with tools like APIClarity. Pandey said that there are quite a few things that developers and security teams can both do to stay up-to-date on API security and ensure best practices.
First, Pandey has three tips for ensuring that APIs and any other application code pulled from another source is safe.
As for how to implement those practices, Pandey recommends looking for software solutions that tie all those things together. Additionally, he recommends using as few native services from cloud providers as possible, and instead only going with managed services.
“If you need something like container management, go with Kubernetes or some other open source product, but offload your site reliability and other managed services to the cloud. The more of their offerings you get, the more locked in you are,” Pandey said.
If you are going to stick with native services, be sure to ask the right questions when signing up, like future access, migratability and the like, Pandey said.
If you want to get started integrating APIClarity into your API best practices, you can download it at the GitHub link above, and you can learn more about it by watching this APIClarity webinar from the Cloud Native Computing Foundation.