API Security: Programmability Is Required

Lori Mac VittiePrincipal Evangelist

Whether applications or APIs, traditional, modern, or AI applications, programmability is a key tool in the security toolbox for dealing with security issues.

One of the ways we keep applications and APIs safe is through testing for vulnerabilities and correctness before unleashing them on customers and partners. A popular technique for testing applications and APIs is fuzz testing.

Fuzz testing involves sending unexpected input—strings instead of numbers, special characters, too long, too short, etc.—to ascertain the API or application’s response. A robust implementation will handle these inputs by rejecting them as invalid. But just as important as testing input handling is testing the code that performs the input handling.

In other words, it’s not enough that the application or API logic rejects invalid input; the logic that checks for invalid input must also be robust.

Now, as is often the case in the world of application security, someone will devise an input that wasn’t expected or considered. We’ll ignore that a good number of input sanitization implementations are simply bad and pretend that they’re all robust and able to catch 99% of malformations.

Even with that utopian assumption, there’s always that 1% that no one considered. That’s one of the ways that zero-day vulnerabilities are born.

Sometimes they’re the result of a defect in the tech stack. Maybe it’s the web server, the app server, the GraphQL server. Maybe it’s in a connector to a data source, like a vector database used to support the increasingly popular retrieval-augmented generation (RAG) use case for generative AI. Or maybe it’s the arrival of AI inferencing vulnerabilities, like Probllama. The addition of a new tier within the broader application architecture means new vulnerabilities, after all.

These are the vulnerabilities that lead to panic on the Internet. They gave us Apache Killer (2011), HeartBleed (2014), Spectre and Meltdown (2018), and Log4Shell (2021).

These were unforeseen vulnerabilities. Developers, SecOps, DevSecOps, and QA could not be expected to anticipate them. They really couldn’t.

Irrespective of the lack of prescience on the part of developers and security professionals, when a zero-day vulnerability appears, something needs to be done. Especially if an organization would be vulnerable because it’s running the technology in question. That’s what pushes risk into threat, and threats need to be neutralized.

That’s where programmability of application services enters the chat.

Programmability of application services is nothing new. Organizations have been using programmability since the early days of the Internet to implement a variety of solutions.

The most common uses of programmability in the data path include:

1. Security: Programmability is vital for mitigating zero-day threats and addressing emerging security risks.
2. Application mediation: Facilitates seamless user experiences during application upgrades and migrations, supports modernization, and integrates new APIs cost-effectively.
3. Service orchestration: Integrates workflows and third-party services into applications without user disruption, expediting time to market.
4. Availability: Supports load balancing and modern delivery practices like canary deployments and A/B testing.

We know these are common because our internal data tells us they are. More than 70% of our customers use programmability daily for a wide variety of solutions. Some of them are focused on security.

So it was no surprise when we surveyed the market in general and found programmability at the top of important technical capabilities for API security.

The versatility of an API security solution that supports programmability is virtually limitless. And while F5 certainly pioneered the capability, it’s become a market staple for application services in general. There are very few application services—and particularly, those focused on securing applications and APIs—that do not provide programmability as part of their core capabilities.

That’s because programmability is the basis for mitigating zero-day threats and enabling organizations to more deliberately design patch plans that impact a significant percentage of their systems.

Programmability does, well, just about anything. But in the realm of security—especially API security—it is not just a “nice to have.” It’s a must have.

For more API insights, check out our State of Application Strategy Report: API Security.

About the Author

Lori Mac VittiePrincipal Evangelist

More blogs by Lori Mac Vittie