Securing Your APIs: Strategies and Components Using API Gateway

AWS API Gateway is an API management platform from Amazon that allows you to create, publish, maintain, and monitor APIs in an easy and scalable way. Like any API management platform, it’s important to ensure that security measures are in place to protect the company’s data and infrastructure.

We will bring in this article some of the main measures to protect your APIS, as well as some other strategies and interesting concepts to be used:

The Basics: Authentication

One of the key security measures to implement in AWS API Gateway is authentication. This includes verifying user credentials, such as username and password, and verifying API keys. Authentication can be implemented using mechanisms such as Amazon Cognito and Auth0, and can be configured to require users to authenticate before accessing APIs.

Speaking at the Api Gateway level, AWS provides authorization options integrated directly with Amazon Cognito, where you can manage the entire aspect of access and tokens, or even a custom authorizer using a lambda to validate credentials.

Authorizer module with option of integration with Cognito or Lambda.

Avoiding headaches: WAF

An important security measure to consider in the AWS API Gateway is the use of the web application firewall (WAF). A WAF is a security tool that acts as the first barrier to entry for our apis. By validating calls even before the API runs, it monitors and controls web traffic to identify and block malicious attacks such as SQL injection, denial-of-service (DoS) attacks, and other threats.

AWS WAF is a fully managed solution that can be integrated with AWS API Gateway to secure your APIs. It allows you to create security rules based on content criteria, such as keywords, regular expressions, and headers, to block malicious traffic before it reaches your APIs. In addition, it provides detailed reports on blocked and allowed requests so that you can quickly identify and fix any security issues.

Also worth mentioning, AWS WAF has predefined sets of protection rules, which makes it an extremely easy and useful tool to use. The basic rule is: Don’t leave the house without it.

WAF configuration area within APIGateway

Limiting the number of calls: Throttling

Throttling is the process of limiting the number of requests that can be made to an API in a given period of time. This is done to protect the API from traffic overload and ensure that it can continue to function in a stable manner.

The request rate is the average number of requests that can be made to an API per second. For example, if the request rate is set to 10 requests per second, this means that, on average, only 10 requests per second will be allowed.

The token bucket algorithm is used to implement throttling in API Gateway. It works by creating a “bucket” of tokens, where each token represents an allowed request. When a request is made, a token is removed from the bucket. If the bucket is empty, additional requests are blocked until tokens are added back to the bucket. Request rate and burst capacity are used to determine the rate at which tokens are added to the bucket.

Security First: Data Transport

In addition to protecting your APIS architecturally and logically, it is important to implement security measures to protect the data transmitted through them. This includes using security protocols, such as HTTPS, to encrypt the transmitted information, and validating the input data to ensure that it is in the correct format and does not contain malicious data.

The popular: OAuth

One of the key security requirements is Open Authorization (OAuth), which is an open authorization protocol that allows users to share their information with other applications securely. OAuth allows users to grant access to their information without sharing their credentials, such as username and password. It is widely used to authorize access to third-party resources such as social media accounts and cloud storage services.

OAuth 2.0 Diagram

Show yours I show mine: MTLS

Another important security protocol is Mutual TLS (MTLS), which is an extension of the HTTPS protocol that adds client-to-request authentication, not just server-to-request. It allows clients to authenticate each other using digital certificates, which is useful in scenarios where you need to ensure that requests only come from trusted sources. MTLS can be used to secure traffic between the customer and AWS API Gateway, ensuring that requests only come from trusted sources.

MTLS communication model

Ugly but efficient: the JWT

In addition to the previous measures, we also have JWT (JSON Web Token), a security protocol that allows you to transmit information securely over untrusted networks. It is a compact, self-contained format for representing authentication and authorization information that can be digitally signed or encrypted. It is used to transmit authentication information between the client and AWS API Gateway, ensuring that requests only come from trusted sources.

The difference between a signed JWT and an encrypted JWT is the way the information is protected. A signed JWT uses a digital signature to ensure that the information contained in the JWT has not been altered during transmission. This is done using a signature algorithm, such as HMAC or RSA, and a secret key shared between the sender and receiver. The signature is added to the JWT and can be verified by the receiver to ensure the integrity of the information.

Already an encrypted JWT, in addition to being signed, is encrypted to ensure the privacy of the information contained in it. This is done using encryption algorithms, such as AES or RSA, and a secret key shared between the sender and receiver. Encryption ensures that the information contained in the JWT can only be read by the authorized receiver, as a key is needed to decrypt the information.

Standard structure of a JWT

Layered Protection

When we talk about API security there are numerous important concepts to be used, some are mandatory, others are complementary strategies that should be used on a case-by-case basis. The important thing is to always remember that the protection of your API is built in layers and, although there will never be a definitive method, there are several models tested and validated by the market.

Here’s an example of different AWS components and the stages at which they can be used:

Different stages and different components that can help you

To summarize, security is a vital part of managing and exposing your APIs, and when it comes to how to secure them, there are a number of useful, easy-to-use tools and strategies in conjunction with API Gateway. Always balance the measures so that one complements the other, primarily evaluating the scenarios of use and criticality of the API.