If you’re seeing zero API attacks, you’re probably not detecting them

Last month, an ESG/Data Theorem survey about cloud-native applications and application programming interface (API) security found that 92% of 397 respondents had experienced at least one API-related security incident in the previous year. 

(It shouldn’t be too surprising; 75% of respondents reported that they typically change their APIs on a daily or weekly basis, making for a constantly churning API attack surface that’s a bear to protect.)

Think that 92% of orgs experiencing API assaults sounds crazy high? 

Bah! It’s probably higher than that, says Contrast Security CISO David Lindner. “I would guess the other 8% did but never detected it,” he hypothesized in his June 6 CISO Insights column. 

As we’ve said before, feeble API security = feeble application security, and APIs are everywhere. They run in mobile apps, awesome JavaScript browser interfaces and rich clients, for starters. Take Netflix: It runs over 1,000 microservices, each managing a separate part of the enterprise, including user management, billing, subscription management, video transcoding, personalized recommendations and more.  APIs are used throughout myriad industries, including retail, transportation and the Internet of Things (IoT), where they show up in autonomous vehicles, smart cities and baby monitors, for example. 

It’s easy to forget: APIs need the same AppSec as apps

When I ask Lindner to unpack his grim conclusion — i.e., it’s likely that 100% are experiencing API incidents, with that 8% probably just oblivious about those incidents — he likens APIs to apps. “The security generalist in me says, ‘[API security is] no different than just traditional application security,” he says. “It is a URL. It is an IP address that is exposed to the Internet that takes some data to do some stuff.”

One difference, though, is that it’s “a lot easier” to forget that APIs need the same security practices as applications, Lindner says. 

It’s just too easy to churn out APIs, he says: “Someone says, ‘Hey. I need the ability to quickly do [something] a thousand times without having to go through the rigamarole of logging into the [user interface].” 

An example: Let’s say that, for some reason — maybe because they believe they're all false positives — a Contrast customer wants to mark all SQL injection vulnerabilities as fixed. There’s up to 20,000 of them, and the customer wants an API to do it.

Creating that API is fast, it’s easy, and the customer gets what they want — happy outcome, right?

The downside: “All these companies are exposing all these APIs because of business needs because they make things more efficient,” Lindner says. “But when you start doing that a lot of times they forget about their access control.” 

Be it via applications or APIs, data gets exposed. “It’s just exposed differently,” he says. “Everyone's creating these apps, and they need [them] to get data. They needed to get data from the back end, so APIs were the way to go. … APIs are really the only efficient way to query the things they need, where they can still have a layer of control over how it's done and how it's returned, and who can access it.

“API creation and usage really became popular with mobile apps. But for whatever reason, when mobile apps [were] developed, it's like we totally forgot that, ‘Hey, someone can still just make that request directly,’ and if you're not securing that request, they're just going to be able to get whatever they want.”

But that’s just part of it. Lindner suspects that, more to the point, any organization that isn’t seeing API incidents just plain isn’t looking for them. 

API incidents are ubiquitous

As it is, script kiddies are constantly poking around, and mass scans happen all day long, every day, “from whatever country you can imagine,” at any endpoint that’s out there, the CISO says. “If you don't have the appropriate detection mechanisms in place, you're never going to see these things, and there's no way to have protections everywhere,” he stresses. 

“So if 92% are saying that they've seen some incident, or an attack, or whatever it is (and 92% does seem high), to me, that's saying they just notice some attacks, which of course they're going to,” Lindner surmises. “I have a pretty good gut feeling that the other eight are also experiencing the same things [but] they don't even know where they are, because they don't have the appropriate detection mechanisms in place to see it.”

Much depends on how organizations define “incident.” Just because the survey respondents are detecting people scanning their APIs doesn’t mean that those scans result in successful exploits or breaches; it doesn't mean that those doing the scanning got anything out of it.  

But if you're not securing API requests, those incidents could, in fact, turn into breaches, Lindner advises. 

Just assume all data requests are a threat

Back when Lindner was training developers, he’d remind them to treat all requests as untrusted and as if they were already compromised, and then consider how to handle that scenario. 

“I think that changes their mindset a little bit, and it's no different for APIs,” he continues. An attacker could, for example, look at an API request to see what they could modify or what controls they may be able to bypass — for example, by modifying the username or by removing the [JSON Web Token (JWT) authentication]. An attacker might be able to use whatever they find to compromise an account or gain access to data they’re not authorized to view. 

Often, API data requests are restful, Lindner notes, meaning that there’s no session ID; instead, they’re just requests and responses. “That reminds me of a really old attack pattern,” Lindner says:. “Most mobile applications early on, they'd be like, ‘Oh, well, it's Lisa.’ Then the back-end API said, ‘It is Lisa,  so I’m going to trust that the API  is responding appropriately. And I'm just going to now be Lisa.’ Because it's using an API that's not using a session. The reality is an attacker could modify that response saying it is Lisa or Dave or whoever they want it to be, and the mobile app would just trust that.”

We’ve got to threat model these things

Contrast is just a small company, but we have thousands of APIs, Lindner says. To deal with APIs at any scale, “You have to do threat models of your API landscape,” he advises. “Discuss threats. Figure out, ‘How could an attacker take advantage of these? Are we appropriately validating and verifying that, for each specific API, that it's validating who it is?’ Maybe [determine] what organization they're a part of — whatever the key pieces are.”

On top of that, make sure there are appropriate security tests. Even with threat modeling, APIs are still all run through the Contrast platform, since “we dog-food our own stuff,” Lindner says. 

You’ve got to do it. You’ve got to threat model every new API, Lindner emphasizes, because when someone says, “‘Hey, we want to create this new API,’ what they really mean is they're going to create 20 APIs for one function, but they all do a little bit different things in a different way.” 

Best to do a light threat model, he suggests — “Just to make sure the key pieces are there, from a security perspective.”

Experience Contrast Security today. Schedule a one-to-one demo to see what the Contrast Secure Code platform could do for you.