How Secure Is Your API Gateway?
Quick, how many APIs does your organization use? We’re talking for internal products, for external services and even for infrastructure management such as Amazon’s S3 object storage or Kubernetes. If you don’t know the answer, you are hardly alone. In survey after survey, CIOs and CISOs admit they don’t have an accurate catalog of all their APIs. Yet the march toward greater use of APIs is inevitable, driven by continued adoption of API-centric technology paradigms like cloud native computing and microservices.
According to statistics shared by Mark O’Neill, chief of research for software engineering at Gartner, in 2022:
- 98% of organizations use or are planning to use internal APIs, up from 88% in 2019
- 94% of organizations use or are planning to use public APIs provided by third parties, up from 52% in 2019
- 90% of organizations use or are planning to use private APIs provided by partners, up from 68% in 2019
- 80% of organizations provide or are planning to provide publicly exposed APIs, up from 46% in 2019
API Gateways Remain Critical Infrastructure Components
To deal with this rapid growth and the management and security challenges it creates, CIOs, Platform Ops teams, and cloud architects are turning to API gateways to centrally manage API traffic. API gateways help discover, manage, observe and secure API traffic on a network.
In truth, API gateways are a function that can be performed by either a reverse proxy or load balancer, and increasingly, an ingress controller. We know this for a fact because many NGINX open source users configure their NGINX instances specifically to manage API traffic.
This requires considerable customization, however, so it’s not surprising that many DevOps teams instead choose to deploy an API gateway that is already configured to handle some of the most important use cases for API management, like NGINX Plus.
API gateways improve security by acting as a central point of control and access for external applications accessing APIs. They can enforce authentication and authorization policies, as well as implement rate limiting and other security measures to protect against malicious attacks and unauthorized access.
Additionally, API gateways can encrypt data in transit and provide visibility and monitoring capabilities to help identify and prevent security breaches. API gateways can also prioritize traffic, enforce service-level agreements (SLAs) or business decisions around API usage, and conserve network and compute resources.
Once installed and fully deployed, API gateways tend to be sticky and hard to remove. So ensuring that you pick the right API gateway the first time is imperative. The stakes are high. Not all API gateways offer the same level of security, latency, observability and flexibility.
Some rely on underlying open source technologies that can cause security vulnerabilities or difficulties with reliability. Others may require cumbersome integration steps and generate unforeseen traffic latencies. All of these can affect the security of your API gateway and need to be considered during the selection process.
What’s under the Hood Matters — A Lot
The majority of API gateway solutions on the market are built atop modified versions of open source software. NGINX, HAProxy, Envoy and Traefik are all commonly used. However, many API gateway solutions are closed source (they use open source wrapped in proprietary code). That said, such proprietary solutions are still completely dependent on the underlying security of the open source components.
This can create significant security gaps. When a vulnerability is announced in an open source project underlying a proprietary API gateway solution, it may take months for the gateway vendor to push a security patch because any changes to the reverse proxy layer require regression testing and other quality assurance measures to ensure the fix does not affect stability or performance. Attackers know this and often look to target the exposed and unpatched open source layers in these products.
The bottom line? You need to know which technologies are part of your API gateway. Dependencies on third parties for modules and foundational components, either open source or proprietary, can generate unacceptable risks if you require a highly secure solution for your APIs.
Audit Your Security Dependencies with a Software Bill of Materials
Creating a software bill of material (SBOM) is one of the most common ways to assess potential vulnerabilities. Simply put, an SBOM is a detailed inventory of all the software components, commercial and open source, that make up an application. To learn more about SBOMs, read “Create a Software Bill of Materials for Your Operating System.”
Once you have a full picture of your software stack, you can assess whether all your items meet your security and compliance standards. You’ll often find that many tools have embedded dependencies within them. Some projects are actively maintained and release patches for known CVEs (common vulnerabilities and exposures) with a standardized service-level agreement.
But many major open source projects are not commercial entities, so they might not issue SLAs on vulnerability disclosure or guaranteed patch times, leaving you more vulnerable to CVEs. That, in turn, can unintentionally put your services out of compliance with the required standards. For those reasons, you need to verify whether each individual component in your SBOM can be made compliant.
You can read “How to Prepare Your Apps for Regulated Markets” for more information about auditing your software technology stack.
Easy Integration with Other Security Controls Is Critical
While API gateways are a critical part of API security, they are only one element. Most organizations running API gateways also need a web application firewall (WAF) in front of their gateway to block attacks (OWASP API Security Top 10 and others). If their infrastructure is distributed, they need more than one WAF. In larger enterprises, the API gateway needs to integrate with a global firewall that polices all traffic going in or out.
Even newer API security solutions that help with challenges like API discovery and threat analysis depend on robust integration with an API gateway. These tools often rely on the API gateway for visibility into API traffic, and usually work with the API gateway to address any emerging threats.
In all cases, tight integration between the API gateway and security tools is critical for maintaining effective security. It’s most convenient if you can use a single monitoring solution to track both firewall and gateway traffic.
This can be a challenging integration, particularly if an organization is operating in a multicloud or hybrid environment. Integration challenges can also mean that changes to gateway configurations require updates to the WAF or global firewall, adding to team workloads or — worst case — slowing down application development teams that have to wait for their firewall or gateway configuration requests to be synced.
Policy Granularity Can Vary Widely across Environments
In theory, an API gateway can enforce the same policy no matter what environment it is operating in. The reality is very different if you have to build your API gateways from different mixtures of components in different environments.
For example, an API management solution might use one underlying open source technology for on-premises or hosted installations of its API gateway and another for cloud services. Policy granularity and all of the resulting security benefits can also be starkly limited by the underlying foundational reverse proxy itself, or the mismatch of capabilities between the two implementations.
For these reasons, it’s critical to run an extensive proof of concept (POC) that closely emulates live production traffic. It’s the only way to be sure the API gateway solution can provide the type of policy granularity and control you require for your growing API constellation.
Inadequate policy granularity and control can result in less agile security capabilities, often reducing the API gateway to a blunt instrument rather than the finely honed scalpel required for managing the rapidly shifting attack surface of your API landscape.
Speed Matters to Application Development Teams
How fast an API gateway can pass traffic safely while still enforcing policies is of critical importance to application teams and API owners. Slow APIs can affect overall performance of applications in compounding ways by forcing dependent processes to wait, generating a poor user experience.
Teams forced to deal with slow APIs are more likely to circumvent security systems or roll their own to improve performance and better control user experience and dependencies. This is the API equivalent of shadow IT, and it creates considerable security risks if APIs are not properly locked down, tested and monitored.
The API gateway alone must be fast. But it’s equally important to look at the latency hit generated by the combination of WAF and API gateway. Ideally, the two are tightly integrated, reducing the need to slow down packets. This is another reason why a near-production POC is crucial for making the right decision.
Conclusion: Your API Gateway Security Mileage Can Vary — Choose Wisely
APIs are the future of technology infrastructure and composable, loosely coupled applications. Their rapid proliferation is likely to accelerate as more and more organizations move to the cloud, microservices and other decoupled and distributed computing paradigms.
Even if you are going against the tide and moving in the opposite direction to monoliths, your applications still need to manage APIs to communicate with the rest of the world, including partners, customers, storage layers, payment providers like Stripe, critical cloud services like CDNs and more.
An API gateway is a serious purchase requiring careful consideration. The most important consideration of all, naturally, is security.
The four criteria we laid out in this post — reliable underlying technology, easy integration with security tools, policy granularity across environments and low latency — are just a few of the many boxes an API gateway needs to check before you put it into production.
Choose wisely, think deeply, and may the API force be with you!
