Protecting API Endpoints Makes APIs Hard to Secure
There is no lack of statistics regarding the (in)security of APIs. A cursory search of the Internet will net you just about any perspective on the topic you like. Suffice to say that (a) API attacks are on the rise and (b) some of those attacks are successful.
It is also common to note that organizations struggle with simply finding all the APIs lurking in their organization. That’s not just because those APIs are sprawled across core, cloud, and edge. It’s because aside from the well-known Open API Specification (OAS) there are no real “standards” upon which to rely for defining, let alone finding, APIs.
That doesn’t mean we need them. After all, we had SOAP and WSDL and UDDI and well, while folks are still using them and relying on XML as a data format, most of the world has moved onto REST, JSON, GraphQL, and gRPC.
Even if we had standards, it wouldn’t change the fact that APIs are hard to secure.
That’s because the term API is an umbrella. For example, The OpenTelemetry API is simply a way to say, “we are making the capabilities of OpenTelemetry available to developers.” It’s not as if you have a security policy that can cover “the” Open Telemetry API. That would be ideal and make things a whole lot easier. But that’s not what we have. What we have are security policies that cover the OpenTelemetry API endpoints.
Let’s dig into that, shall we?
APIs and Endpoints
Let’s use the Open AI API for our example because everyone is all agog over generative AI right now.
The first thing you’ll realize is that even though there’s only “one” API, there are many endpoints. How many? That number changes every time new capabilities are introduced.
Here’s a (not comprehensive list):
- https://api.openai.com/v1/chat/completions
- https://api.openai.com/v1/audio/speech
- https://api.openai.com/v1/audio/transcriptions
- https://api.openai.com/v1/audio/translations
- https://api.openai.com/v1/embeddings
- https://api.openai.com/v1/fine_tuning/jobs
- https://api.openai.com/v1/files
Multi-modal generative AI adds media—audio and video—to the list of content types but adds new endpoints to handle processing requests. Additional features, like the use of Tools, may expand the number of endpoints as well. Every advance—every new capability we get excited about—typically adds another endpoint to the API.
You’ll also note the “v1” in those endpoints. That means that when v2 comes out, there will need to be another set of security policies to cover these endpoints, and some of those policies will need to change based on whatever changed in the actual endpoint.
This is also extant in the IT stack, where automation is accomplished via device APIs. The number of endpoints depends largely on your environment. The more devices you have under management, the more endpoints you need to manage and secure. Oh, and let’s not forget that no two devices use the same API. I mean, that’d be crazy, wouldn’t it? Almost like two cloud providers agreeing to use the same API. This is probably why “complexity” remains the most cited reason for not automating a variety of operational tasks. Too many tools and APIs make it difficult to automate and even harder to secure.
But API security must address all those endpoints because they are how attackers get in. And each endpoint requires a different set of parameters that end up in the payload as JSON (or XML or GraphQL or <insert format here> objects). There need to be limits on what each parameter can contain: Is it alphanumeric? Characters? A range of values? How long can it be? What characters are not allowed? All this information is translated into a policy that enforces what the content looks like and, in doing so, prevents attacks from sneaking through.
Building a policy for just the Open AI API is going to take some time. And it’s just one API. Most organizations have an average of 442.8 APIs according to our upcoming 2024 research, and that number skyrockets for very large organizations. Consider how many endpoints—and versions of endpoints—that could mean, and it becomes clear very quickly why API security is so darn hard.
And why attackers are successful enough to keep targeting them.