“The main takeaway is that if you already have some kind of API strategy and an API gateway, that’s a great way to start the API security journey. In most organizations, the security team is very much in line with the program. When it comes to API security, their goal is not to stop you from developing your APIs. The goal is actually to help ensure that the API can be used safely over time and that you can build more and more APIs.”
– Giora Engel, Co-Founder, and CEO at Neosec
This week on the API Intersection podcast, we spoke with Giora Engel, Co-Founder and CEO at Neosec. While API security is always a hot topic (check out our other episode on this with Curity on the matter), we can never get enough of how to improve and ensure it’s a vital consideration of the entire API development lifecycle. Giora sat down with us to explain some of the critical things security teams seek from API developers and how we can all partner for secure and effective APIs.
At the end of the day, visibility into your API development is what the security team seeks, and having it can actually help developers.
“If you can have that visibility, you can see how it’s used. You can even debug your system better than you would today because if your logs are better if your visibility is better, you can do more with the data. So this is a clear case where there is a win-win between the security and developer teams,” shares Giora.
A New Frontier for Security
“I think the enterprise security space is very well known to security people, but application security and APIs are a very new frontier, and everything seems to be happening there right now,” shares Giora.
From an attacker’s perspective, things were very different ten years ago compared to the landscape today. Often, there were breaches where somebody compromised an employee’s devices and then moved inside the network or found servers in their data center. But, if you look at any organizations today, everything that tech teams are building is full of application environments and APIs that are, by design, exposed to the outside world to operate effectively.
“So all of a sudden, you’re kind of exposing everything to the outside by design, and from a security perspective, most security teams don’t even have an idea of where to start when it comes to APIs,” shares Giora.
The security team doesn’t really develop the API. Therefore they are often one step removed from the process. Most of the development lifecycle happens before an API hits production. And very few people (often DevOps folks)even see what happens in production.
“Usually, people working on the API are not necessarily thinking about what’s going on inside the application, how it’s used, and in some cases, being abused. I think that the problem starts with the lack of visibility on how these APIs are used,” shares Giora.
Giora emphasizes that the importance is really in discovering and taking proper inventory of your APIs so that your security team has that visibility from the get-go. This means creating an inventory (or a catalog), documenting it, and ensuring that the inventory is updated frequently because these APIs constantly change.
In reality, however, APIs shift and change over time, and the documentation doesn’t always change with the API depending on the tools that you’re using. So, an organization like NeoSec helps solve that issue by creating a dynamic inventory of your APIs and comparing it to the well-known documentation.
“When we find something that is not already documented, we flag it. Typically, we see in practice that there are whole services not being documented because there’s more focus on documenting APIs that are supposed to be used by other developers. Often teams will put less of a focus on documenting admin interfaces or other interfaces that are really inherent but not necessarily needed by others,” shares Giora.
In addition to APIs that deal with admin interfaces, Giora emphasizes that there is often less of a focus on properly maintaining documentation of older APIs as well.
“So we take the approach of, by observing the traffic, we can recreate all the documentation and compare it to existing documentation. Then, just to complete the picture, we also look for vulnerabilities, misinformation, misconfigurations, and deployment issues with the APIs and also look for behavioral anomalies,” shares Giora.
To prevent some of these vulnerabilities that Giora’s team looks for, it’s essential to have a well-designed API that prevents some of those security issues, in addition to ensuring your developers understand the risk of not properly documenting or maintaining their APIs.
Common Examples of API Abuse & Potential Vulnerability
“The most common abuse cases are actually ones that don’t look like abuse. Basically, it’s using the APIs in a technically okay way. It’s authorized; it’s not using a vulnerability even. But if you’re scraping data, let’s say you’re accessing too many objects for example, it’s still a mistake that produces vulnerabilities,” shares Giora.
In the Medical Field
Let’s look at a typical medical provider. One of their partnerships is with another hospital that needs to access the data to provide treatment. So, their tech team could implement the API in a way that actually takes all the records to their side, does some processing, and then provides that data. Alternatively, they can just retrieve one specific record that they need. Here is where a simple mistake within this process could be made beyond your control as the API author where you can expose the data.
“These are typically a lot of cases that we see where your other party gets compromised; then the APIs can also be used against you,” shares Giora.
In the Payments Field
Another example we can use is when we look at a payment platform. If you’re a payment provider and you have merchants transacting on your platform, and then one of the merchants gets compromised, then all the data and transactions that at least that merchant has access to can be compromised, reversed, or suburbanized.
“That’s kind of a clear use case where the APIs technically are used in a way that is authorized and clean, but because of account takeover, it can be used against you,” shares Giora.
Innumerable Parameters Example
Another common vulnerability is one called innumerable parameters. This means that most of the parameters you use in building your APIs should not be sequential, easy to guess, ones that are on top of other controls, or ones that are part of other authorization controls you need to implement.
However, if your credentials get compromised, then that attacker can at least get access to your objects that you normally have access to, meaning they don’t necessarily need to guess the numbers since they are already authorized as ‘you.’
Consider Putting Security Standards in Your Style Guides
“There are a lot of security guidelines that you should consider when designing APIs,” shares Giora.
Incorporating those checks and standards into your own API style guides from the start can help ensure security is not forgotten during the development process. This provides another opportunity for your security team and API team to sync on the API design and catch possible vulnerabilities early on. Incorporating all relevant stakeholders (such as your security team), in the design process is a significant component of following the design-first approach anyways, so it’s definitely something we recommend.
But as a final reminder from Giora, it’s important to note that “the other side of it is that you need to accept the fact that because you’re designing flexible microservices, you’re inherently giving more access than absolutely needed for a particular service. Therefore, security is even more vital because of the purposeful increased exposure.”
Check out the resources below for better practices and work around API security. As always, subscribe to the API Design blog or our podcast for more insights.
