The Role of API Gateways in API Security

This article is featured in the new DZone Guide to API Management: Comparative Views of Real World Design. Get your free copy for more insightful articles, industry statistics, and more!

When switching from a monolith application to microservices, the behavior from the client side cannot be the same as it was, where the client had one entry point to the application.

Now, when working with microservices, the client has to deal with all the complexity that comes from a microservices architecture, like aggregating the data from various services, maintaining several endpoints, the increased chattiness of client and server, and having separate authentication for each service.

Client dependency on microservices directly makes it difficult to refactor the services, as well. An intuitive way to do this is to hide these services behind a new service layer and provide APIs that are tailored to each client.

This aggregator service layer is also known as an API Gateway, and it is a common way to tackle this problem.

API Gateway-based microservices architecture pattern.

All requests from clients first go through the API Gateway. It then routes requests to the appropriate microservice.

A typical API Gateway includes:

• Security (authentication and potentially authorization)
• Managing access quotas and throttling
• Caching (proxy statements and cache)
• API composition and processing
• Routing (possibly processing) to an "internal" API
• API health monitoring (performance monitoring)
• Versioning (possibly automation)

API Gateway Advantages

• Implemented in a single place
• Simplifies the API source code itself, since these concerns are externalized
• Provides a central and unique view of the API and therefore be more likely to allow a consistent policy

API Gateway Drawbacks

• Possible single point of failure or bottleneck
• Risk of complexity since all the API rules are in one place
• Risk of lock-in, and migration may not be simple

API Growth Creates Opportunities, Vulnerabilities

To get a grasp on the runaway growth of APIs, one needs only to look at statistics from ProgrammableWeb, which has been tracking publicly exposed APIs since 2005. At that time, there were only around 100 APIs listed; today, there are more than 10,000 publicly known APIs.

That growth is increasingly underpinning an economy that is reliant on treasure troves of user data. Salesforce.com reportedly generates more than 50% of its $3 billion in annual revenue through its APIs, and nearly 90% of Expedia's $2 billion in annual revenue.

Companies generate API revenue by metering access to APIs and the resources behind them in a variety of ways. For instance, Twitter, Facebook, and others provide ad-based APIs that allow for targeted advertisements based on reporting and analytics, but ad agencies and other brands must pay for access to those APIs.

The API Gateway's Role in Security: Identity and Access

Access control is the number-one security driver for API Gateway technology, serving as a governor of sorts so an organization can manage who can access an API and establish rules around how data requests are handled.

Cheshire said access control almost always extends to establish other policies, including rate limits on API calls from certain sources, or even payment requirements for accessing all or certain resources through an API.

When all traffic is routed through a gateway, IT security experts feel more confident that they have their finger on the pulse of an organization.

An API Gateway's access control capabilities usually start with authentication mechanisms to determine the actual source of any API calls. Currently, the most popular gateway is OAuth, which acts as an intermediary for accessing web-based resources without exposing a password to the service, with key-based authentication reserved for instances in which the business can afford to lose the data because it's difficult to guarantee complete secrecy of the keys.

Message Security

Gateways are a great way to route all API transactions through a single channel for evaluating, transforming, and securing messages across an organization. When all traffic is routed through a gateway, IT security experts feel more confident that they have their finger on the pulse of an organization.

API Gateway can introduce message security between the internal services making the internal services to be more secure and the messages going back and forth between the services encrypted.

Ignoring proper authentication — even if transport layer encryption (TLS) is used — can cause problems. With a valid mobile number in an API request, for instance, any person could get personal email addresses and device identification data. Industry-standard strong authentication and authorization mechanisms like OAuth/OpenIDConnect, in conjunction with TLS, are critical.

Threat Protection

Without threat protection, the API Gateway, its APIs, and the native services of the integration server are basically insecure. That means potential hackers, malware, or any anonymous outsiders could easily attempt to propagate a series of attacks such as DDoS or SQL injection.

APIs are the gateways for enterprises to digitally connect with the world. Unfortunately, there are malicious users who aim to gain access to backend systems by injecting unintended commands or expressions to drop, delete, update, and even create arbitrary data available to APIs.

In October 2014, for example, Drupal announced a SQL injection vulnerability that granted attackers access to databases, code, and file directories. The attack was so severe that attackers may have copied all data out of clients' sites. There are many types of injection threats, but the most common are SQL Injection, RegExInjection, and XML Injection. More than once, we have seen APIs go live without threat protection — it's not uncommon.

Logging

Many API developers become comfortable using 200 for all success requests, 404 for all failures, 500 for some internal server errors, and, in some extreme cases, 200 with a failure message in the body, on top of a detailed stack trace. A stack trace can potentially become an information leak to a malicious user when it reveals underlying design or architecture implementations in the form of package names, class names, framework names, versions, server names, and SQL queries.

It's a good practice to return a "balanced" error object, with the right HTTP status code, minimum required error messages, and no stack trace during error conditions. This will improve error handling and protect API implementation details from an attacker.

The API Gateway can be used to transform backend error messages into standardized messages so that all error messages look similar; this also eliminates exposing the backend code structure.

Whitelists and Whitelist-Allowable Methods

Considering API traffic at the IP address level, there should be a known list of devices, servers, networks, and client IP addresses. Depending on the tightness of the network, this list will vary in size.

It is common with RESTful services to allow multiple methods to access a given URL for different operations on that entity. For example, a GET request might read the entity, while PUT would update an existing entity, POST would create a new entity, and DELETE would delete an existing entity.

It is important for the service to properly restrict the allowable verbs such that only the allowed verbs would work, while all others would return a proper response code (for example, a403 Forbidden).

Input Validations

Taking advantage of loose input validations allowing a hacker to find the gaps in a system. Using existing inputs, an attacker will explore what is accepted or rejected and push what is possible until they find a way into an API and break down the system's integrity.

Here are the most common input validations.

Message Size

It is good to have message size limitations. If you know with 100%certainty that you are not going to receive large messages (for example, more than 2MB), why not filter them out?

SQL Injection

SQL injection protection allows you to block requests that could possibly cause an SQL injection attack.

JSON Threat Protection

JavaScript Object Notation (JSON) is vulnerable to content-level attacks. Such attacks attempt to use huge JSON files to overwhelm the parser and eventually crash the service.

XML Threat Protection

Malicious attacks on XML applications typically involve large, recursive payloads, XPath/XSLT or SQL injections, and CData to overwhelm the parser and eventually crash the service.

For more info about input validations, please visit here.

Rate Limiting

Requiring authentication for all API users, and the logging of all API calls made allow API providers to limit the rate of consumption for all API users. Many API Gateways allow you to put caps on the number of API calls that can be made for any single API resource, dictating consumption by the second, minute, day, or other relevant constraint.

API Gateways: Open Source

Here are some of the products worth checking out:

• Tyk
• WSO2 API Manager
• Kong Community Edition

Conclusion

When talking about API security, we must understand that security is the number-one concern of companies, organizations, institutions, and government agencies considering investing more resources into their API infrastructure, as well as companies that are ramping up their existing efforts. At the same time, it is also the most deficient area when it comes to investment in API infrastructure by existing API providers. Many companies are building APIs as products on their own, deploying web, mobile, IoT, and other applications, but rarely stopping to properly secure things at each step along the way, but API Gateways are one of the most popular and efficient solutions for the many security problems you'll face.

This article is featured in the new DZone Guide to API Management: Comparative Views of Real World Design. Get your free copy for more insightful articles, industry statistics, and more!