Three things every CISO should know about API security

In the third episode of the F5 Global CISO: For defenders by defenders, I was joined  by Corey Ball, one of my favorite API hackers. Corey’s been active in IT and cyber security for the past 15 years, and literally wrote the book on hacking APIs when he found that there really wasn’t much in the way of collected knowledge on the topic, and this is when we first met.

The book is Hacking APIs: Breaking Web Application Programming Interfaces, which provides a crash course in web API security testing. Corey also was a founder of APIsec University, a free resource for learning about API security, and is founder and CEO of hAPI Labs, which performs API security and web app penetration testing.

Corey is clearly an expert on API security, so I asked him the question of the day: What are the three things every CISO should know about API security? In particular, I wanted to know what he thought defenders could learn from looking at API security from the attacker’s perspective.

APIs are the technology behind the transfer of data—one of the world's most valuable resources. “But while we put up layers of defense like firewalls and web app firewalls to protect this data,” Corey said, “APIs that are internet-facing can often be a gateway to compromise.” If there's an unsecured API that doesn't require authentication or enforce authorization, it can be a direct opening for a criminal attacker, who can come in, make unauthorized requests, and steal the data that’s protected with all those other layers.

“I want to make sure that defenders understand that they need to use the right tools and approaches to test their API security,” he said. It’s not enough to just point an automated scanner at an API, get a clean report, and assume everything is safe. Defenders need to actively test and analyze API requests to uncover real issues and address any actual security issues that exist.

Testing your testers. One practical way to validate testing skills and tools, according to Corey, is to practice against intentionally vulnerable applications, which are safe, purpose-built targets that allow testers to experience, reproduce, and understand common types of API security problems. “For instance, the OWASP API Security Project offers crAPI, a training tool which is deliberately filled with API vulnerabilities, and built for the purpose of teaching, learning, and practicing API security. You can point your scanner directly at crAPI and see what results you receive.” If only surface-level vulnerabilities are found, like missing HSTS headers or misconfigured clickjack protections, your testing tool may be overlooking more serious API vulnerabilities, such as those in the OWASP API Top 10.  “This would demonstrate that your testing tools may not be as effective as you think,” Corey said.

Corey and I also discussed that classic enterprise vulnerability tools and management programs don't work for APIs, because APIs are vulnerable to different types of attacks than those that target traditional web apps. For instance, broken object level authorization (BOLA) and broken object property level authorization (BOPLA) are API security flaws that are tied to the API’s core business logic. I asked Corey, if a company has deployed a WAF and an API gateway, what are they missing in terms of protecting APIs?

WAFs and API gateways are critical for app security and user authentication, he said, but they aren’t enough on their own to protect APIs. The biggest challenge of securing APIs is authorization, which is making sure that users can only access, see, modify, or delete their own data. “You need to make sure that user A can only interact with user A's resources. They can't change, read, update, or delete user B's resources,” he said. “Authorization in APIs is definitely challenging. A criminal attacker's request for someone else's resources is going to look a lot like a valid request, unless fine-grained authorization rules are in place.”

Authorization controls need to be part of a multi-layered approach to API security that combines multiple, complimentary controls so that if one layer fails, others still provide protection.

As organizations increasingly invest in generative AI and AI-powered apps, they need to understand that these technologies increase the API attack surface. That’s because generative AI applications are APIs “all the way down.” In other words, a world of AI is a world of APIs, the underlying structure of generative AI apps relies heavily on APIs, and nearly every part of the AI system is exposed through these interfaces.

But, as Corey and I discussed, APIs are only part of the challenge of securing AI apps and architectures: AI engines and large language models (LLMs) also expose other vulnerabilities to attack. For instance, the Model Context Protocol (MCP) is an open-source standard that provides a unified framework for connecting LLMs to external tools and services. While MCPs offers many benefits for integrating AI into apps, they also present significant security challenges. “When you look behind the scenes at generative AI,” said Corey, “it’s already a bunch of APIs, and then you introduce MCPs, which are often vulnerable due to weak authentication and authorization controls—though security protections are catching up.”

Another security consideration of MCPs is prompt injection attacks and natural language hacking. “These can lead to business risk when you have AI agents and chatbots representing your company. Attackers can manipulate your AI agents to say something unsavory that doesn’t represent your business well, or persuade chatbots into giving unauthorized discounts.” Organizations also need to understand that chatbots can be considered legal representatives of the company and held legally responsible for their statements and actions. Companies need to be careful—they don’t want to miss the business opportunities that AI apps present, but they also need to take due diligence to ensure that AI apps and chatbots are trained on accurate data and secured against prompt injections.

It's always a pleasure to catch up with Corey, and I’d like to thank him for joining me to discuss what defenders can learn by looking at security from the attacker’s perspective. As defenders, our defense must be informed by the offense, so we all need to understand how the offense works and what these operators are looking for so we can intelligently align our limited resources into a layered defense that makes sense for your enterprise, ministry, or agency.