Every API falls into one of two categories: Internal or external.
External APIs are APIs that developers use to integrate their applications with a third-party resource, such as a public cloud service or a SaaS application. This type of API is probably what you think of first and foremost when you think about APIs.
However, there are also internal APIs. These are the APIs that handle communication between the constituent parts of an application. More and more apps are moving to a microservices-based architecture and therefore internal APIs are becoming increasingly important.
Which type of API -- internal or external -- is subject to greater security risks? You may be tempted to say “external” because the stakes of security incidents involving external resources tend to be higher. But the reality is more complicated than that. Here’s an overview of the different types of
API security attacks that could impact both types of APIs, along with tips on why even internal APIs may be deeply insecure.
API security attacks against external APIs
External APIs may seem less secure because, by definition, they bridge your application with an external environment. There may be problems with authentication and authorization when using an external API that could easily expose your internal resources to unauthorized third-party access. Unlike internal APIs, you often lack visibility into the level of these risks.
The risk of external APIs is especially high in cases where APIs allow use of global tokens. In this case, a user could authenticate, then use the API token to access resources that should only be available to another user. For example, under a poorly designed external API, a malicious user could log into a banking app, gain a token and use the token to access account details for a separate user.
Internal API security
The security threats that impact internal APIs are not fundamentally different from external API vulnerabilities. They boil down to problems with access control and authorization, such as the use of global tokens or failure to enforce service-to-service API authentication.
However, internal API security risks are generally less severe. The main reason why is that when a security risk arises with internal APIs, it typically cannot be exploited by external attackers. Provided you properly lock down your network, threat actors would already need to have access to your internal environment in order to exploit an internal API security flaw.
In addition, because internal APIs are usually not shared with third parties, developers don’t need to worry about internal API security threats expanding to impact partner organizations or customers. They only have to manage the internal fallout.
Finally, internal API security issues can often be addressed internally by developers modifying any code that they deploy in-house. Even if the code was borrowed from a third-party open source project, it’s theoretically possible to change it without having to ask external developers for help.
Why internal APIs are not always more secure
The above notwithstanding, it’s important to keep in mind that internal API calls are not always less vulnerable to security issues. In certain ways, external APIs are easier to secure.
Above all, common external API security vulnerabilities are often documented in public news releases. By following these releases or performing vulnerability scanning on your software, you can track external APIs that are subject to known security disclosures. That’s not possible in the case of internal APIs whose security flaws developers usually uncover on their own.
It may also be more difficult to collect data from internal APIs for security monitoring purposes. You must design APIs to expose the necessary information for tracking and monitoring, and developers who build internal APIs may not take the time to optimize visibility into their APIs. In the case of external APIs, developers usually create more visibility because they know that API consumers will require it.
Finally, the stakes of internal API security can be quite high in the sense that internal API security issues could make it easier for attackers to break into an environment or escalate their privileges once they establish a beachhead. This could occur if your network is not properly locked down. For instance, an attacker who compromises one of your app’s microservices could spread the attack to the rest of the application if the APIs that manage communication between the microservices lack strict access controls.
As another example, internal API security problems could allow attackers to bypass security controls that you attempt to enforce through other tools. You could define security contexts in Kubernetes to isolate pods, for instance. But if insecure internal APIs allow pods to share data through APIs, security contexts that isolate workloads at the container level won’t actually do much to prevent communication between pods.
All APIs can be insecure
In short, no matter whether you are managing internal or external APIs -- or, for that matter, whether your APIs use
REST, SOAP or any other architecture -- you should never assume they are secure. Although in general external APIs are riskier in many respects, insecure API calls involving internal APIs could have severe consequences for application and data security too.
API security, requires a multi-pronged approach that addresses the various types of security threats and severity levels that may impact both internal and external APIs.
Contact us for a free trial or to learn more about what it takes to manage these threats in an efficient, systematic way.
