5 min read
by Peter Bosch
Published on 10/05/2021
Last updated on 02/05/2024
Published on 10/05/2021
Last updated on 02/05/2024
API security attacks against external APIsExternal 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 securityThe 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 secureThe 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 insecureIn 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.
Get emerging insights on emerging technology straight to your inbox.
Unlocking Multi-Cloud Security: Panoptica's Graph-Based Approach
Discover why security teams rely on Panoptica's graph-based technology to navigate and prioritize risks across multi-cloud landscapes, enhancing accuracy and resilience in safeguarding diverse ecosystems.
The Shift keeps you at the forefront of cloud native modern applications, application security, generative AI, quantum computing, and other groundbreaking innovations that are shaping the future of technology.