API Management Gateways Don’t Provide Enough Security

The rise of the API economy is also driving the adoption of tools for managing and securing a plethora of new APIs. In some respects, API management gateways are a modern solution for the age-old challenge of extending existing applications to solve more problems. Over the years, the various terminology and technology implementations have evolved to address the best practices of the day.

Throughout this evolution, the management and security aspects of integration evolved along separate paths that eventually joined together. The management aspects have traditionally focused on making it easy to reuse services across multiple applications, including a focus on making services discoverable, composable, and reusable. These solutions have always included a basic level of governance, identity, and access management.

Security solutions evolved along a parallel track to protect the perimeter of the infrastructure. Over the years, this perimeter has grown beyond secured local area networks using virtual private networks. The growth of new internet services drove the need for firewalls, Web Application Firewalls (WAF), and Runtime Application Self-Protection (RASP) to address new kinds of threats not addressed by existing security and management tools.

These threats are giving rise to a new industry of API-specific security capabilities outside the scope of current management tools. In some regards, this is simply an extension of the need for firewalls, VLANs, WAFs, and RASPs to complement other application integration tools.

The evolution of the API gateway

The history of modern API gateways can be traced back to the rise of enterprise application integration in the 1980s to improve the efficiency of enterprise application development. Enterprises were rapidly adopting more packaged software and customizing solutions for specific business workflows. But the addition of each new application also led to a dramatic increase in the number of integrations for sharing data across applications.

Enterprises began exploring ways to create a tier of middleware that could link various databases and services spanning enterprise resource planning, payroll, customer relationship management, and business intelligence. Many of these early efforts failed as executives grappled with technical challenges, office politics, and vendor efforts to restrict API access to their own ecosystem of tools.

In the early 2000s, the industry rallied behind service-oriented architectures built using enterprise service busses (ESBs). Over time, enterprises also explored ways to extend these across partners using various industry-specific B2B hubs to exchange EDI messages. B2B exchanges managed the security between trusted partners. The development of web services brought a lot more flexibility to these integration efforts. New tools like NGINX emerged to create a high availability proxy to balance traffic across multiple back-end servers.

Around 2010, Google, Twilio, Stripe, and other companies began exposing business class services through APIs. A new generation of API gateways emerged to simplify monetization, analytics, documentation, and controls. Other enterprises realized that many more business applications could be decomposed into services hidden behind an API.

This encouraged legacy enterprise vendors like Tibco and Oracle to extend their ESB offering to support more modern API management practices. A new generation of nimbler ESB vendors including MuleSoft and Apigee similarly pivoted to API management gateways. NGINX extended its web proxy to support API management. Other companies such as Kong extended the core functionality of the open-source NGINX core to support more robust management and controls.

The rise of cloud architectures drove enterprises to consider how to scale applications across applications composed of much smaller microservices tied together via APIs. Twitter and other companies began discussing ways to break complex monolithic applications into collections of microservices. These microservices drove the need for more sophisticated API gateways. The second generation of API gateways began adding more functionality for authentication, rate limiting, and routing. This allowed teams to build smaller, more agile services that could be updated independently of each other.

Major cloud vendors realized API gateways could also provide a convenient on-ramp to their respective cloud services. Google bought Apigee, Salesforce bought MuleSoft, and Amazon rolled out the AWS API Gateway.

The limits API gateway security

All API gateways provide a variety of core security functionality for authenticating API users, protecting sensitive data, monetizing usage, rate limiting, and security policy management. They provide essential safeguards for checking a user’s credentials and also include features for protecting against denial-of-service attacks.

They support various functionality for authentication, authorization, generating an audit trail, and ensuring compliance. API gateways also include various policy management capabilities for dynamically creating and updating security and usage policies for multiple classes of users. They work in concert with a separate Identity and Access Management system to provide centralized controls across APIs and other services.

While API gateways provide some basic protections, they also leave open many avenues for attack, summed up in the OWASP API Security Top 10. API gateways are more focused on protecting the front door of APIs rather than what goes on behind the door. They function much like the bouncer at the door to ensure that only people with the appropriate ID can get through. But they can be fooled by fake or compromised credentials, just like underage kids flashing fake IDs to get into the nightclub. And a bouncer at the entrance might miss unwanted behavior going on inside the club.

The rise in the value of services protected by APIs motivates hackers to find new strategies to compromise them, such as searching for unsecured API keys and discovering applications with hard-coded credentials. And hackers are getting creative about finding API logic flaws and perfecting attacks by sniffing out API calls.

Filling the gaps

Addressing these latest threats requires a variety of new processes outside the scope of traditional API gateways. New API security tools like Traceable help fill the gaps. For example, API discovery capabilities monitor stately API traffic to provide full visibility across all APIs.

These tools also illuminate what is happening inside APIs. For example, Traceable helps identify when API endpoints handle sensitive data, even when it originates in other APIs. Traceable can also perform more robust security analytics at the business logic layer to identify threats that might be missed at the gateway. Like a sophisticated camera at the casino, this technology can zero in to spot new cheating techniques at the playing tables.

Over time, API gateways will expand support for more sophisticated security analytics and response capabilities to protect against new vulnerabilities highlighted in the OWASP Top 10 API list. But this may take a while — API gateway vendors are still filling in OWASP vulnerabilities identified almost two decades ago. In the meantime, better integration between API management and API security tools will play a vital role in protecting against the next wave of threats.

About the Author

George Lawton is a technology writer and regular contributor to The Inside Trace.