A lot of attention in API security today is focused around implementing a sound security strategy across an API’s lifecycle, from design to deployment. But not all APIs in use by organizations are written internally. These so-called third-party APIs may be used as part of a functional digital supply chain or for management of key infrastructure components. As with all APIs, these APIs – developed by partners and other outsiders – fuel innovation and operational efficiency. And like all APIs, they also contribute to a sprawling API attack surface and can be a security risk if not properly accounted for. Since these APIs are developed and published outside the typical DevOps cycle that an internally developed API moves through, they frequently are not properly inventoried, governed, tested, monitored, or maintained. This lack of oversight poses a large array of security risks to an application and its underlying infrastructure.
Third-party APIs are Contributing to API Sprawl
Third-party APIs are sometimes referred to as ghost or ghostwritten APIs, because they provide important functionality but are written by outside entities, and in many cases, they run within the infrastructure invisible to API governance program controls.
API sprawl continues to be a major issue that every organization is wrestling with today. As companies seek to maximize the business value of APIs, they have proliferated. It is no secret that digital transformation initiatives, cloud migration projects, API-first app architectures, partner-enablement programs, and advancements in rapid continuous software deployment methods have fueled the high pace and number of APIs created, deployed, and in use by organizations. To complicate matters, most APIs serve a variety of teams, across many different locations. API sprawl manifests itself far and wide in an organization and occurs across multiple teams, multiple technology platforms (legacy, Kubernetes, VMs, etc.), and multiple infrastructures (on-premise data centers, multiple public clouds, etc.).
The Salt Labs Q3 2022 State of API Security Report revealed that 53% of respondents identified API sprawl (in terms of Shadow/Unknown or Zombie/Outdated APIs) as their greatest concern when it comes to API security risks. However, the fact that often gets overlooked when it comes to API sprawl is that it extends beyond in-house developed APIs. Many organizations are unaware that the deployment and use of third-party APIs, exposed both internally and externally, increases the attack surface for bad actors.
Third-party APIs find their way into corporate infrastructure both intentionally and unintentionally from a variety of sources and extend the potential attack surface in different ways. Some examples include:
- Commercial packaged applications: Many packaged applications expose an API for integration and interaction, but what sometimes gets overlooked is that they also leverage API-first design principles for their UX and admin interfaces, which exposes a larger amount of endpoints, even if they’re not used. Often, organizations use only a small subset of the endpoints published in purchased packaged apps, but just running those apps mean they expose all of the APIs or API functionality associated with it.
- Open-source applications: The widespread adoption of containers, Docker, and Kubernetes makes it easier than ever before to find, pull, and launch third-party open source apps and services. Just like their commercial counterparts, lots of open source applications today have adopted API-first design principles that expose many API endpoints that your organization may or may not use or even really see. Consider, for example, an open source app or service that a developer or architect wants to leverage as a functional piece of an application. When the app starts, the service, unbeknownst to the developer, automatically launches and exposes an admin UX and an underlying API which supports it. This behavior inadvertently increases the attack surface of the application.
- No-Code/Low-Code Frameworks: The threat associated with these frameworks is that they give non-developers the ability to create ad hoc tools, apps, and APIs. They offer lots of value in terms of speed and efficiency, but without the proper controls in place, their output can contribute to a sprawling attack surface. Frequently, these non-developer developers don’t even realize they’ve produced an API. As an example, consider a business analyst who uses a no-code framework to build an internal service to share customer data. Built outside of normal development controls, and without deep developer understanding, it’s easy to see how the person building the service wouldn’t even know it’s an API enabling that data delivery, much less that the API might have no authentication mechanism and no adherence to any API publishing guidelines that internally developed APIs must follow. Now, consider the case where a developer learns of this API and decides to use it as part of another application. The framework-generated API has now been promoted from just an internal tool to something more significant – but all under the radar, outside of any API governance and security controls. This risk is one many organizations are trying to get their arms around today.
- Incorporating SaaS Services Into Application Architectures: Many organizations rely on third-party, cloud-based services as part of their functional digital supply chain. Most often, the integration with the third-party SaaS platform happens over APIs. While those APIs are technically developed and owned by the third-party provider, any sensitive data flowing through it is still owned by the client using that app. The APIs of the SaaS service extend the functional architectural footprint and attack surface of the application. It becomes problematic to keep track of where these third-party SaaS service APIs are in use when organizations have many teams architecting and developing many applications across different technology platforms, often incorporating multiple third-party SaaS services into their applications.
- On-premise and cloud-based infrastructure management APIs: Today, physical appliance, virtual appliance, and cloud-based infrastructure companies have adopted management by API principles and/or API-first design principles to enable management of that infrastructure via a variety of methods including API, mobile app, or UX. Not properly accounting for and securing the APIs associated with managing critical infrastructure components ultimately leaves organizations with increased risk. Consider the risk, for example, if an API key used to manage a company’s cloud infrastructure through the cloud provider’s API is unknowingly compromised. Would the company be able to detect the third-party API abuse?
Don’t Assume Third-party APIs are Secure
No organization gets a “free pass” on API security just because it did not develop a given API. The developers of the third-party APIs face the same API security challenges as the rest of us, and their APIs can be exploited and abused if not properly built and protected. With third-party or ghost APIs, organizations exert no influence over how the APIs are developed or whether those outside developers follow API security best practices.
Recently both Fortinet and F5 had to address separate critical Admin API vulnerabilities that were being utilized by attackers in the wild. These vulnerabilities allowed attackers to compromise their respective solutions (FortiOS, FortiProxy, and Fort Switch Manage from Fortigate and BIG-IP and BIG-IQ from F5). These recently revealed vulnerabilities should serve as a reminder that it can be costly to assume that just because someone else wrote the API, the API’s endpoints are not susceptible to business logic flaws, API abuses, or any other of the API security risks outlined in the OWASP API Top 10.
In addition, as social engineering and phishing attacks continue to advance in sophistication, threat actors more and more frequently are gaining access to internal-only infrastructure. This reality was on display in the Dropbox disclosure last month, where Dropbox outlined how it fell victim to a social engineering attack that allowed an attacker to gain access to 130 of its source code repositories, which included access to API keys used by Dropbox developers. Whether intended for internal consumption only or not, APIs, including those developed by third parties, must be properly protected.
Best Practices for Tackling Third-party API Sprawl and Security
Organizations can take several steps to help better secure third-party APIs in their infrastructure:
- Include Third-party APIs In Your Organization’s API Inventory: Because of the many sources that may produce third-party APIs, and the wide range of roles they can play, it is important to employ best practices that will provide an extensive inventory of where third-party APIs are in use, how they are used, their place in a digital supply chain, and the type of data that is interacting with them. Just knowing a virtual appliance or packaged application or open source service exists is not enough context from a security perspective. Employing proper onboarding governance and documentation when a new third-party API gets used by a developer and utilizing API discovery scanning technology to identify third-party APIs in use will greatly aid in providing the visibility needed.
- Subject Third-party APIs to Appropriate Security Testing: Just because you didn’t develop those APIs doesn’t mean you can’t scan them for known vulnerabilities. Leverage in-house DAST capability to scan third-party APIs in use to better understand their security posture and any surface risk they may introduce before you accept them as part of your digital supply chain and infrastructure management.
- Utilize an API Gateway in Front of Third-party APIs: Third-party APIs, especially if they play critical roles in the delivery of digital services and infrastructure management, should be treated the same as if they were internally developed, from a governance and security perspective. Organizations should use an API gateway to manage access, authentication, and authorization to those APIs. This governance should extend to all sources of APIs (packaged apps, open source, no-code frameworks, SaaS services, infrastructure management, etc.). As a general rule, use an API gateway to allow access only to the APIs and underlying endpoints that are necessary for the service and block all endpoints that are not. In addition, an API gateway can provide visibility and control where there is none typically. For example, many organizations, such as small to medium-size banks that do not host APIs in their own infrastructure but instead leverage SaaS-to-SaaS API integrations and services to run their businesses, have begun to adopt this pattern as a way to gain visibility and control over third-party APIs – and, even more crucially, the valuable, regulated data that flows through them.
- Monitor and Protect Third-party APIs with Proper API Runtime Protection: An attacker does not care who developed the API. Any API, no matter who built it and no matter how and where it is exposed, must be subject to discovery and runtime protection so that organizations can detect API abuse. Applying API runtime protection to internal as well as third-party APIs provides immediate protection for all known and previously unknown APIs. Monitoring the full scope of APIs in runtime gives organizations an understanding of normal API usage, enabling them to quickly spot potential abuses. With these insights, organizations can quickly pinpoint and block attackers who are trying to leverage zero day vulnerabilities – and with APIs, remember that all vulnerabilities are zero-day vulnerabilities, because all APIs are unique. Runtime protection will prevent exploits against newly discovered vulnerabilities, like the ones related to the Fortinet and F5 appliances mentioned earlier, or find attackers who are poking around, searching for business logic holes and weak points in your APIs they can attack.
