API Security Fundamentals

What are APIs?

APIs have become a critical part of our technology infrastructure. We expose the digital capability via an API, no matter what we develop (a product or solution) or how we develop (different programming languages). There is enough information already available on justifying the use of API and how they help developers to develop their solutions faster without any friction.

Since APIs are so important and they carry vital information about our company, colleagues, products, etc., it is important to ensure that our APIs are available but cannot be exploited.

Securing our APIs

Securing an API should not be a challenging task as the teams should follow pre-defined configurations that they can use to protect their APIs. API security is applied at three distinct levels to avoid targeted attacks.

Figure 1: Security Layers

We will look at different mechanisms available under these security levels and discuss how we should protect our APIs using the method.

Infrastructure & Network Level Security

This is our first line of defense and all the controls at this level ensure that any un-trusted client or malicious connections are blocked before it reaches our APIs. Protection at the infrastructure and network levels is enabled by using a mix of products that sit at the edge and are managed and operated by a central infrastructure team using standard policies. These are applied to a group of APIs without any specific consideration to specific APIs. Standard control points enforce at the level are –

· Firewall

· DDoS

· WAF

· Load Balancer

Figure 2: Network and Infrastructure security components

As shown in the above diagram, each layer adds a layer of protection and depends on the layer above it to block illegitimate connections. These control points become mandatory when our APIs are exposed to external consumers and developers.

Application-level Security

Based on the criticality of a business service and the type of data it carries, we would apply one or many configurable policies to secure them. Security at this level assumes that the communication has been protected by using the components from Network & Infrastructure before it reaches to APIs. Standard control points at this layer are –

· Authentication & Authorization

· Schema Validation

· Rate Limiting

In a distributed architecture, the application is built using layers where each layer provides a unique capability to the overall function of the service. There is no restriction on the number of layers, a business service can have however it would have a minimum of two layers –

1. API Proxy Layer

2. API Implementation Layer

Figure 3: Application Security

We will not discuss the technology and products that are available to build these layers, but the focus will be on securing the connections and data flowing through these layers. Sometimes the teams put a lot of focus on enabling security at the API proxy layer but forget to secure the connection between the proxy and API implementation. This may lead to API implementation being vulnerable to attacks.

We will be looking at three ways, we can secure the connection between these two layers.

1. Principal Propagation:

In this approach, the API Proxy uses the bearer token that it received in the input request and attaches the same bearer token to the outgoing request (API implementation). This method is efficient as the bearer token is generated once and propagated to different systems for authorization however this method has a vulnerability if we rely solely on the bearer token –

“API Consumer could bypass API proxy and access the API implementation directly using the bearer token.”

Figure 4: Principle propagation using Oauth 2 bearer token

To overcome this challenge, we must add other security schemes to our API implementation to secure the connection between API Proxy and implementation –

a. Establish trust at the Network level — Secure API implementation network so that only API Gateway can communicate to the implementation. There are several ways using which the network connection can be secured between the API proxy and the implementation layer. Teams can use different subnets or VPC peering (if the components are deployed in different VPCs).

b. Use PKI — If a dedicated network connection between the API proxy and API implementation layer is not feasible, setting up an mTLS link between API Gateway and implementation will ensure only the gateway can talk to underlying API implementation using client-server certificates. This method can be used as an additional security layer on top of a dedicated network if enhanced security is required by teams.

c. Protect API implementation using client id and secret created specifically for the API Gateway and configure these in a secure, encrypted way in the gateway.

2. Generate a new bearer token in the proxy layer

In this approach, the API proxy will register itself on the authorization server as the consumer of the API implementation and generate a new bearer token. It will attach this new bearer token to the outgoing request. Even though it is a simplified approach, it involves generating an extra JWT token for every transaction and will increase latency. This also requires API Gateway to have the intelligence to connect to an Authorization server to generate the bearer token.

It is important that the teams building APIs must enforce the security principles outlined above. Teams can add more complex authorization schemes on the API implementation layer using OPA (Open Policy Agent) or they may choose to add additional security layers between an API proxy and API implementation.

Data Level Security

While it is important to secure the connection between different components in our solution and ensure that only legitimate consumers can access the endpoint, we need to also ensure that they can access data items that they have been authorized to access. For ex — we will provide a distinct set of data items based on who is consuming the API. It may be a system that is authorized to a certain data set of a user initiating the transaction using a specific system. In both cases, they will be using the same API however their data access requirements would be different.

Some of these checks can be performed on the API proxy layer using scopes and claims passed in the bearer token whilst more sophisticated checks would require a policy engine like OPA (Open Policy Agent)