Building and Securing API Gateway Architecture

As with all content accessed over the internet, APIs and API gateways are vulnerable to myriad threats if not properly secured. Without appropriate authentication and authorization in place, your application can be accessed by anyone who cares to look.

API Security

If the connection from clients to your API gateway isn't encrypted, all messages you send and receive are out in the open for all to read. In looking for a way in, attackers will make use of all features of an API, even the undocumented ones; security by obscurity is not a realistic defense measure.

By definition, APIs provide programmatic access to your application, making them a large attack vector for malicious actors. Brute force attacks can be used to discover login credentials, giving attackers access to a user's account and a platform from which to seek out more vulnerabilities. By including invalid content in an API request, malicious code can be injected directly into a system; SQL injection and cross-site scripting are the best known forms of this attack. Denial of service and distributed denial of service attacks can be used to take an application offline by hitting it with more requests than it can handle and consuming all its resources.

Securing an Existing API Gateway

An API gateway decouples the backend microservices from the public interface of your application, providing a central access point for your APIs. While this simplifies access to the application for clients, it also provides a central platform for implementing security best practices, applying them consistently to all your APIs.

HTTPS Communication

Whether you've inherited an existing API gateway or you're conducting a security audit of your existing setup, one of the first items on your list should be to ensure all communications between the API gateway and clients are sent over HTTPS, even if authentication is not required. For content that should be restricted to logged in users, a reliable, secure authentication method is essential. This includes following API authentication best practices to make it much harder for attackers to impersonate a valid user by discovering their username and password. Both of these features can be implemented at the API gateway level, rather than on the individual microservices. This avoids duplication of effort for developers and ensures a consistent approach across your application.

API Threat Defense

When defending against other types of threat, such as denial of service, brute force and injection, an API gateway offers an additional line of defense. While injection attacks can be guarded against with server-side and client-side validation on the data being sent, a regex check at the API gateway can prevent malicious code reaching the server side. Rate limiting, request/response size limiting and throttling can be used not just to manage spikes in activity but to defend against repeated calls from attackers or bots. Adding logging to an API gateway provides an audit trail for all calls made to your APIs, so you can verify what data has been accessed.

By combining the data available from these tools, it's possible to build up a picture of the traffic hitting your application at any one time. A web application firewall (WAF) analyzes this data in real time to identify potential threats. Malicious actors can be blocked automatically, with machine learning applied to constantly improve the service.

Of course, all of these measures can be compromised if an attacker gains admin access to your API gateway. The Kong API Gateway provides a fully-secured, RBAC-controlled Admin API that can be additionally secured against unauthorized use with network layer access restrictions, specified IP ranges for access from outside the network and fine-grained access control by using Kong as a proxy to access its own API.

API Security and Gateway Best Practices

As well as the security measures discussed above, you can further improve the security of an API gateway by factoring this into the design phase. When building an API gateway, consider which endpoints need to be exposed and to whom.

Data Security

Many API gateways fall into the trap of exposing too much information and relying on the client to filter out any unnecessary data. Those extra details can be gold dust in the wrong hands, providing insight into your application architecture with verbose stack traces or even giving access to data that should not be available. Designing endpoints and error codes to meet the intended use cases but no more than that avoids too much information being exposed.

In a similar vein, the HTTP headers included in a response from a REST API can include information about the server and platform which can be used to exploit the system. By applying a transformation to a response at the API gateway, you can sanitize the outbound data to send only what is needed.

API Led Connectivity

If your application has multiple different use cases, such as mobile apps, IoT devices and integration with internal systems, consider creating separate API gateways for each one. This avoids exposing endpoints that are only intended for internal use, for example, to the wider world. To prevent unauthorized access, an API gateway for internal applications can be restricted to your organization's network or operate a whitelist of authorized clients.

Managing Deprecated APIs

Finally, it's essential to keep track of your APIs: ensure you remove any APIs that are no longer in use and deprecate old versions which do not include new security measures implemented at the application level. Managing your APIs through an API gateway gives you oversight of all your APIs and the ability to measure and analyze their usage.