Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
Share
INSIGHTS
9 min read
Share
Forrester dubbed API Insecurity "the lurking threat in your software." Understanding API security-specific risks is key to protecting your API. New ways of thinking about API security are emerging.
Using external services through APIs is routinely done to speed up development cycles in today’s microservices architecture. Unfortunately, this potentially creates additional exposure for the application. When calling external services or data from an enterprise application, penetration vectors cloaked in these external sources might expose databases or the application back-end to attacks.
API security is the process of securing the application against importing vulnerabilities from external services through REST calls, REST, OpenAPI, gRPC, graphQL, and ad-hoc interfaces. Regardless of the architecture used, Gartner identifies API security as a new attack surface potentially leading to data breaches. So, in this post, we will focus on API security across all platforms, and not on Kubernetes as we usually do.
Tackling API security risks requires an understanding of what the specific security challenges they face are. Here are six OSWAP most critical challenges, listed in order of decreasing importance:
Accessing external resources or services through third-party APIs generates a risk of exposing critical information through these external providers' APIs’ vulnerability. These might provide entry vectors for malicious actors to infiltrate the application, leading to potential information leaks or application service disruption.
Currently API security is rigid, with a one directional hierarchical flow that lets developers use whatever API is most convenient to them.. As feature development high velocity is a core requirement for developers, they tend to focus more on delivering fast than on dwelling on security aspects. To make matters worse, API qualifications are often unclear, further diminishing the odds that developers will take the time to fully understand the API security implications of the feature they are developing.
So, API security is more of an afterthought, taken into account only when SecOps enters the picture and try to assess if the APIs used by the developer are high or low risk. This is a highly manual process, both time-consuming and prone to error. Hidden and/or zombie APIs are often missed and image libraries with vulnerabilities are overlooked. CISOs are responsible for all the applications in your environment. They need visibility, one of the pillars of API security, and this system does not offer it.
We will discuss further API security developments shortly, but in the interim implementing the recommended API security best practices below is a good starting point.
API vulnerabilities are complex to spot as they might originate in application logic flaws, so it is critical to take into account the entire API’s lifecycle and identify the insecure parts. Vulnerabilities need to be identified both for internal and external APIs.
Internal APIs connect an organization's disparate backend system to enable seamless communication for individual lines of business needing access to specific data silos. Identifying and closing vulnerabilities in internal APIs is key to preventing lateral escalation in case of a breach.
External APIs are the interface between the application and external clients, providing services or data. As applications are increasingly assembled with these external services and data, and the quality and security of remote services and databases is oftentimes unknown, the organization’s customer data might be at risk when using a third-party service. Identifying vulnerabilities from third-party providers might be tricky, especially as telemetry API security evaluation is typically not available before runtime, complicating the identification of vulnerability from external services during the CI/CD cycle. With the absence of full control on vulnerability identification for external APIs, the additional methods listed below are especially critical.
Use methods such as TLS (Transport Layer Security) to encrypt data and require signature from a privileged few authorized to decrypt and modify data. This is particularly crucial for PIDs.
API keys provide both project identification and authorization. As such, they are useful to block anonymous traffic and to control and monitor calls to your API, but not to secure traffic to and from your API as they can easily be stolen. To avoid unwanted use of API keys, use secret keys with unique temporary access tokens. Maintain a strict credential discipline to prevent exposing secret/password both to client and server.
Segmentation is key to prevent lateral escalation. This requires creating a strict schema establishing what are the system’s permissible incoming data. All incoming data need to be validated before gaining entry, limiting the odds that they might be harmful.
Log all traffic information and monitor API traffic and consumption.
These API security best practices provide increased security, but existing methods are still inefficient in evaluating vulnerabilities inherited from third-party service providers in real-time and provide an automated response to changing third-party service provider risk factor.
Forrester's October 2020 report on API Insecurity identified the shift away from SOAP APIs to OpenAPI and gRPC, graphQL, and ad-hoc interfaces as one of the current API security exposure sources.
Instead of access through two-way connection to SOAP APIs, REST APIs, OpenAPI,gRPC, graphQL, and ad-hoc interfaces are typically accessed through mobile apps or browsers. This opens applications to easy-to-obtain hacking tools and client-side inspection. The requirement for rapid development cycles makes it virtually impossible to eschew reliance on third-party providers.
What is needed is an oracle that speaks to the risks enterprise applications run when interacting with such services. With an oracle capturing those risks in a “reputation score”, developers, SecOps (or a combination thereof), and CISOs can enable connectivity policies for interactions between the enterprise application and the third party service. The policies can reduce the exposure to API risks for enterprises using third party API services.
To address API reputation scoring and the implications for enterprise applications and their security when using such services, a scoring mechanism for the API service reputation is necessary. This scoring mechanism needs to be able to be used in a DevSecOps environment when developing and hosting applications. Such a scoring system requires:
A scoring system like the above would enable developers to evaluate the cost/risk-benefit of including a third-party API and adapting cybersecurity insurance costs to rise and fall in parallel to the third-party APIs scores. An integrated development system including scoring would also offer visibility to both SecOps and CISOs as to the APIs the developers are using and their risk levels. The security persona receives a list of dependencies with easy visibility into whether all of the used assets are high or low risk. It allows for compliance reports to be generated by a CISO quickly and easily. The CISO can then approach the customer with a list of vulnerabilities and a plan for a solution. There is continuous visibility and risk mitigation is simple by quarantining those API calls quickly and efficiently.
An integrated development system is the way forward. Best practices are invaluable guardrails, but unfortunately, mistakes happen during development so, even if all recommendations are applied, monitoring your application for runtime vulnerabilities still remains critical to ensure ongoing API security.
Looking for an API security solution? Learn more about Panoptica, Cisco’s cloud application security solution.
Get emerging insights on innovative technology straight to your inbox.
Discover how AI assistants can revolutionize your business, from automating routine tasks and improving employee productivity to delivering personalized customer experiences and bridging the AI skills gap.
The Shift is Outshift’s exclusive newsletter.
The latest news and updates on cloud native modern applications, application security, generative AI, quantum computing, and other groundbreaking innovations shaping the future of technology.