What security policies are you missing in your gateway layer?

API architects and designers spend a lot of time discussing the latest security standards and protocols, yet sometimes they end up ignoring some essential security measures for APIs. Occasionally, we get too obsessed with the Authentication and Authorization bit, and we overlook some other security provisions, such as content-based security. In most enterprises, an API gateway or API management layer takes care of the security aspects when they expose APIs for wider consumption. This article focuses on the security measures which should be in place in the gateway layer.

To be clear, the security requirements of APIs differ from domain to domain. For example, a banking or financial API may have stricter security requirements than a retail or telecom sector API. However, some security measures remain the same regardless of the domain or sector of the enterprise. So, here are seven security policies that all APIs should keep in mind:

1. TLS

Let’s start with the most obvious thing: all the APIs should be available on TLS with an HTTPS URL (https://). Having an HTTP URL (https://) is a big NO. Unfortunately, several APIs available today on the internet are still on HTTP. Not having TLS enabled is like an open invitation to all kinds of attacks. Sometimes, enterprises don’t bother to set up TLS for internal APIs as they are intended to be consumed within a secured network.

However, if someone gains unauthorized access to your network, they can easily listen to internal API traffic if it’s on plain HTTP. So, regardless of the purpose and target consumers of an API, you should always secure APIs via TLS. APIs require a pair of private keys and certificates from a trusted Certification Authority (CA). Store this on the API server keystore, and configure your API domain to use this keystore so that API endpoints are called using https:// URLs. As a recommendation, you need to have one-way TLS from client to API gateway layer and two-way TLS from gateway to backend systems host.

2. Protection Against Traffic Spikes

API gateways must protect against sudden spikes in client requests. Backend systems should have certain limitations on the number of requests they can process within a time frame. If a client, or a set of clients, makes too many requests, it might bring down the backend servers, thus denying access to other legitimate consumers. Sometimes client systems might be doing some load tests, which might result in too many API calls, or sometimes it can be a deliberate DDoS attack from a hacker with bad intentions.

In either case, having this security policy would ensure such spikes in API calls from clients are handled properly, and backend servers remain up.

3. Authentication, Authorization, and Identity

This is the basic minimum requirement to protect your APIs against unauthorized access. Based on the API type and use case, one of the following mechanisms need to be applied:

• If your APIs need end-user authentication and consent, they need to be protected by the OAuth2 Authorization Code Grant or OpenID Connect. These makeup the standard security framework for authorization and user identity. More on these can be found on the protocol pages — OAuth2 and OpenId Connect.
• In scenarios where there is no User context or consent required, and the consumer is either an internal trusted app or partner app, the OAuth2 Client Credentials Grant should be used to secure APIs.
• If an API is catering to clients that cannot perform OAuth2 token flows for some reason, then at least API Key security should be applied so that client apps should be authenticated. API keys can be accepted in either the request header or query parameter.

4. Protection Against Parser Attacks

Most of the time, APIs accept JSON or XML payloads in the request. In such scenarios, an attacker can attempt to send input that would overwhelm parsers in the backend services. For example, an attacker could send an array instead of string values, they could send too many garbage fields and values, or include very long values in some fields.

Such kinds of attackers are designed to overwhelm the parsers and break them. That would cause the servers to go down and induce DoS attacks. Therefore, any API that expects JSON or XML payload should have schema or structure level validation to ensure that parsers are safe.

5. Preventing SQL, Script, and Other Injection Attacks

SQL Injection, HTML Script Injection, Java Exception injection, and so many other code injection attacks are quite popular. Within these content-based attacks, hackers try to retrieve data that they are not supposed to. Quite often, APIs do not have provisions to prevent such attacks, leaving backend services vulnerable.

APIs should have some common regular expressions configured, which should be validated against incoming data. There are common Regex patterns available to match against data containing SQL, HTML, and other injection syntaxes. You should perform a generic validation on the incoming data for the same.

6. Masking and Encrypting Sensitive Data

As a rule of thumb, all sensitive data should be either masked (i.e., replaced partially or fully with ***) or encrypted/tokenized. Data like credit card numbers, bank account numbers, and national id numbers are considered sensitive personal information. Each country has its own data protection laws, like PCI, HIPAA, GDPR, etc. API gateways need to ensure they are not logging any such data in plain text in either debug or system logs. Also, to avoid abuse, you should not log OAuth2 tokens or API keys in plain text.

7. Data Signature Verifications

It is imperative to verify the integrity of the incoming data in payload or query string. If there is some proxy server or intermediate system between the client and the API layer, there are chances for a Man in the Middle (MITM) attack or other attacks that temper with request data. Such situations would compromise data integrity.

To counter such issues, you can send a signature of the request data in either a header or payload. These signatures could be generated by the client either using a shared key or a private key (of which the public key should be accessible to the server). The API gateway can then re-generate the signature based on incoming data and match if the newly generated signature is identical to what is there in the request.

Security at the Gateway Level

You may be thinking that all these security measure may impact performance. However, most of the API gateways are equipped with the security measures mentioned above and can rapidly perform such validations. API gateways are the entry to your APIs and services — so, consider them like the main gate to your house. The more it is secured, the more you can sleep peacefully.