Protect APIs

API Protection and API Firewall help you protect your APIs from malicious intents. API Protection generates a protection configuration that is based on the OpenAPI definition of your API, and API Firewall enforces this configuration in runtime.

Both OpenAPI Specification v2 and v3 are supported.

For best results, before you start make sure that the OpenAPI definition of your API is valid and has a satisfactory audit score (at least 70 points). See API Contract Security Audit.

Create a protection configuration

Tailor a protection configuration for your API based on its OpenAPI definition. Protection tokens tie protection configurations to running API Firewall instances.

  1. In 42Crunch Platform, click Protect. The API Protection wizard opens.
  2. Select the API collection and the API you want, and click Configure Protection.
  3. If this is the first protection configuration you create for this API, enter a name for the protection token. If your API has an existing protection configuration, an existing token is used. For more details on managing protection tokens, see Create or revoke protection tokens manually.
  4. If needed, you can switch API Firewall to run in non-blocking mode. This is optional and should be used with caution. For more details, see Non-blocking mode.
  5. Click Review Setup, and verify that the details are as you want them. If you want to change something, you can click on the tabs in the API Protection wizard to jump to the correct section.
  6. When you are ready, click Complete Setup. The protection configuration for the API and the protection token for this configuration are generated.
  7. Copy the token value and save it securely (for example, as a Kubernetes secret). You will need this value when you configure the API Firewall instance.

    API Protection Wizard showing the generated token and the buttons for showig the token value and copying it.

  8. Click Close.

Security riskAlways store all your tokens securely, for example, in Kubernetes Secrets, 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.

If you reconfigure the protection configuration of an API you have previously protected, the existing protection token is not regenerated but stays the same. To change a protection token for an API, you must revoke it and create a new one manually.

TipIf you have several APIs and several environments, it can be difficult to keep track of where each protection token is used. To stay on top of things, in addition to giving descriptive names to protection tokens, use descriptive names for your stored secrets as well, for example, in Kubernetes secrets. We recommend that you include the name of the token and the name or API UUID of the API in the name of the secret. For example, in a Kubernetes secret generic-pixi-protection-token, generic is the name entered for the token when it was created and pixi is the name of the API the token was created for.

Deploy API Firewall

42Crunch Platform provides a common base image for the API Firewall. When you combine the base image with the protection configuration you just created to deploy and run API Firewall in a container orchestrator, such as Kubernetes, you get bespoke protection for your API.

If you are new to API Firewall, we recommend you try our pre-configured sample for the Pixi API to see how deploying an API Firewall instance works.

Note When API Firewall starts, it establishes a a two-way, HTTP/2 gRPC connection to 42Crunch Platform at the address protection.42crunch.com and the port 8001. Make sure that your network configuration (like your network firewall) authorizes these connections. API Firewall uses this connection to verify the protection token and to download the protection configuration you have created. During runtime, API Firewall uses the connection to send logs and monitoring information to the platform.

Test API Firewall

Once you have the API Firewall instance protecting your API up and running, you can send API requests to the protected API to test how the firewall works.

For our sample API, Pixi, we have included a test collection for Postman in the resources repository. This collection provides ready-made malicious calls to easily invoke the Pixi API and see the protection in action. For more details on the sample attacks, see the generic Kubernetes guide in the repository.

The sample attacks might also give you some ideas what to test on your own APIs.

For a practical example, check out the following video on API Firewall in action: