Discussion on APIs featuring Frank Catucci and Dan Murphy

What’s with all the buzz around API security? It’s becoming the top concern in application security as everyone is looking for faster and more reliable ways to secure their ever-growing API ecosystem. In Postman’s 2023 State of the API Report, 92% of respondents said they planned to increase their investments in APIs through 2024, which was up a massive 89% from the previous year. With API usage surging in software development, the line between APIs and applications is getting blurred, even as the security industry seems to treat them as completely separate things.

Invicti recently released API discovery as part of its API Security product to help companies proactively address API-related risks in their application environments—but how does it all work under the hood and what makes it so special? We sat down for an interview with Invicti’s CTO, Frank Catucci, and Chief Architect, Dan Murphy, to clear up some API misconceptions, get closer to the technical side of building API security into an application security platform, and learn why it’s so important to treat APIs not as a separate entity but as an integral part of your attack surface.

This might seem a very obvious question to start with, but we’re seeing a lot of confusion about the differences between web applications and APIs. Especially in the security industry, you see a lot of dedicated API security products and vendors, so it sometimes feels like applications and APIs are two separate things with different security requirements. So what’s your practitioner’s eye view on applications vs. APIs in terms of architecture and, of course, security?

Dan Murphy: I come from a software engineering background and have spent a lot of my career thinking about APIs and web applications. But for folks who don’t necessarily have the same background, it’s sometimes hard to visualize, so it’s valid to ask: What is an API? How does it differ from a web app? And the answer is those things are a little blurred. Many modern applications are single-page applications (SPAs) that are simply invoking APIs as the user clicks around the app, so they’re a kind of hybrid of GUI and API. But with a traditional API, the thing on the other end of the request is not the web browser—it’s a piece of code. It may be some other web service invoking a webhook, some backend code or systems talking to each other, but it’s definitely not a human clicking inside of a browser.

One of the metaphors I like to use is that APIs are like the service elevators in buildings—people coming in the front door don’t see…

Frank Catucci: That’s a great metaphor—APIs are the part of an application that does the heavy lifting in terms of data access and processing, but because they often aren’t visible, they can slip through testing and inventory efforts. So when people ask me what’s so special about APIs and API security, I like to start with an example of an API-based attack, such as the Optus data breach. Now that one was only possible because of an exposed API endpoint that let an attacker download the data of over 10 million customers without any authorization or authentication.

So that Optus API, that service elevator if you like, would allow anybody who figured out the URL to enter a customer number and get confidential information back, and just enumerate those customers without any limits. It was what we call a shadow API that was never intended to be accessible in production, so it didn’t have…

Could you talk a bit more about shadow APIs? We see that term thrown around a lot, so what practical security problems come up with shadow APIs and, more generally, when doing API security rather than securing that more visible part of applications?

Dan: It’s pretty easy for an API, which doesn’t have a user-visible manifestation, to be ignored and go out of date. With a website, a developer or security person can often simply click around and they will quickly notice if anything looks really sketchy. In fact, this is what we do automatically with our Predictive Risk Scoring. But APIs are a lot more difficult for that kind of quick analysis because they don’t have anything that you can directly interact with. They are a catalog of invisible operations that could be performed on a computer. And if you don’t keep track of what’s in that catalog and who’s allowed to do these operations, you can get shadow APIs creeping in, like these hidden service doors that might not be easy to find but aren’t…

Frank: I’m glad you used the word “catalog” because those catalogs or inventories are really the sticking point for API security. So, ideally, you want to keep track of all your API specifications. In reality, they can live in various places and formats, formal and informal. You might have your “official” specs in OpenAPI (aka Swagger) files or Postman collections or your API management system like MuleSoft or whatever else you’re using, but you can also have proxy exports from Fiddler or even…