API Protection

Traditionally, the entry point to an organization's network architecture was through applications that run on dedicated servers and had a thin web application layer. This made it relatively easy to maintain security and protect application servers by setting up a web application firewall (WAF) as the only point of entry to the network.

However, with the rise of APIs, the picture today is very different. Now, the entry point to the network architecture is the plethora of APIs that call the backend to provide the functions of the application. This puts the quality and security of your APIs in the spotlight. APIs provide a contract, but they do not themselves contain adequate measures to ensure that the contract is upheld, posing a serious security risk to the backend services the APIs connect to. Direct access from the Internet to your backend service through the API jeopardizes security.

With so many entry points often widespread in the network architecture, putting a firewall in front of a server is no longer enough to ensure all entry points are protected. In addition, a traditional WAF-based solution has no means to distinguish hacking API calls from legitimate API traffic.

To address these issues, 42Crunch Platform moves that firewall directly in front of your APIs. With API Protection and API Firewall, you can protect your APIs from malicious intents.

Both OpenAPI Specification v2 and v3 are supported.

Security model

Most of the API attacks today could be avoided with proper data validation for both inbound and outbound messages. To make staying on top of security more straight-forward, API Protection uses a positive security model based on strict conformity to the API contract of the protected API. API Protection blocks unwanted requests (like bots) and prevents hackers sending random requests to your APIs to fish for information.

API Protection creates an allowlist of the valid operations and input data based on the API contract, and API Firewall enforces this configuration to all transactions, incoming as well as outgoing responses. Transactions containing things not described in the API definition are automatically blocked. These could be, for example:

  • Messages where the input or output data does not conform to the JSON schema
  • Undocumented methods (POST, PUT, PATCH...)
  • Undocumented error codes
  • Undocumented schemas
  • Undocumented query or path parameters

Audit. Scan. Protect.

Because the security model is based on the OpenAPI definition of the API, the first step is to make sure your API definition conforms to security best practices. For the allowlist to work properly, the API definition must be in good shape.

That is why 42Crunch Platform offers both API Contract Security Audit and API Contract Conformance Scan, so that you have a clear view of how secure your API is before you start protecting it. Making sure your API gets a good score and conforms to the contract set out in its API definition saves you from nasty surprises later on.

Before you start with API Protection, make sure you have done the following:

  • Audit and improve the security of your OpenAPI definition with API Contract Security Audit and Security Editor.
  • Deploy your API in a Kubernetes environment.

For best results, we also recommend scanning your API with API Contract Conformance Scan

API Firewall

API Protection generates a protection configuration for API Firewall based on the OpenAPI definition of your API. API Firewall is an API-native application firewall that acts as the security gateway to your enterprise architecture, and is the single point of entry and exit for all API calls.

API Firewall enforces OAuth and OpenID Connect configuration and runtime best practices, and filters out unwanted requests, such as bot requests or attacks, only letting through the requests that should be allowed. Each API Firewall instance is based on the same base image, but tailored for the API in question based on the protection configuration, and it provides a virtual host for that particular API.

Deployment architecture

API Firewall instances are deployed in Kubernetes clusters together with the APIs they are protecting. You can use your existing deployment files and scripts, or create new ones. The following configuration artifacts are used to configure the Kubernetes deployment for API Firewall:

  • The file deployment.properties encapsulates all API-specific deployment properties.
  • The protection token identifies which protection configuration to run.
  • TLS secret that contains the certificates and corresponding keys for secure connections. The listener interface of the firewall only accepts secure connections. The TLS profile (Mozilla Modern) is preconfigured and embedded in the generated firewall image.

For more details on the deployment files and configuration artifacts, see Deploy API Firewall for your APIs in Kubernetes.

Sidecar mode

In sidecar mode, each API Firewall instance is co-located in the same Kubernetes pod with the API it protects.

The listener interface of API Firewall exposes the endpoint through which all API traffic must pass. API Firewall filters the traffic and only allows through transactions that conform to the contract set out in the API definition. The backend resources and databases that the API points to can be safely deployed behind dedicated services in their own separate pods that only API Firewall can call to. During runtime, API Firewall sends logs and monitoring information to 42Crunch Platform.

The graphic shows an illustration of the components in sidecar mode.

Because the firewall instance is co-located with the API and can communicate only with that API, the hostname is always localhost.

Non-blocking mode

By default, active API Firewall instances protecting an API block any transactions that are in violation of the API contract. However, if needed, you can switch API Protection to non-blocking mode.

Security risk Non-blocking mode leaves your API unprotected! API Firewall instances execute security policies normally but do not block any transactions, they only report on what would have been blocked. Proceed with caution, and only use non-blocking mode when absolutely necessary.

Non-blocking mode may help, for example:

  • Discover any potential issues in introducing API Firewall in the line of API traffic: are existing users blocked and if yes, why
  • Detect false positives, if any
  • Troubleshoot detected problems

For more details, see Switch API Protection to non-blocking mode.

Protection tokens

Protection tokens tie protection configurations you create for your APIs to running API Firewall instances.

When an API Firewall instance starts, it connects to the 42Crunch Platform and fetches the protection configuration matching the protection token specified in the deployment file of the instance. This ensures that the API Firewall instance runs the correct configuration for your API.

Security riskAlways store all your tokens securely, like other secrets you use! Treat tokens as you would other sensitive information, like your passwords.

For security reasons, you cannot view the values of your existing tokens after you have created them. However, you can easily create a new one to view and copy the value.

Multi-environment deployment

Protection tokens enable you to secure your API in multiple environments simultaneously. For example, you could deploy the same API protected with an API Firewall instance using Kubernetes in Microsoft Azure and Amazon Web Services (AWS), but create and assign separate protection tokens for each deployment.

This way, you can manage the different cloud deployments for a single API independently of one another, such as bring one deployment down for updates while the other deployments continue to serve your API consumers.

You can create and revoke protection tokens on the Protection tab of the API as needed. You can also use a protection token in more than one deployment and manage those deployments together.