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, the perimeter defense with WAF in front of a server is no longer enough to ensure all entry points are protected.

To address these issues, 42Crunch API Security Platform moves the defense from the network perimeter to in-depth directly in front of your APIs. With API Protection, you can protect your APIs from malicious intents with an API micro-firewall. The micro-firewall is tailored to your APIs, so it can distinguish hacking API calls from legitimate API traffic, unlike a traditional WAF-based solution.

API Protection is based on the OpenAPI (formerly Swagger) definition of your API. Both OpenAPI Specification v2 and v3 are supported.

Security model

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 requests as well as outgoing responses. Transactions containing things not described in the API definition are automatically blocked:

• 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

The allowlist is on by default, but you can use a 42Crunch vendor extension to the OpenAPI Specification (OAS) to deactive it, see Deactivate automatic contract enforcement in API Firewall.

For more details, see API Firewall.

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 as precise as possible, not only in terms of security but also in data validation.

For example, when an email address is expected, you must define its type (string), pattern (string@mailbox, and only one @ allowed), and length (limited) for it. This ensures that a mail address like john.doe@gmail.com@elysee.fr is rejected (unlike in the Tchap breach).

That is why 42Crunch Platform offers both API Security Audit and API Conformance Scan, so that you have a clear view of how well-constrained your API contract is and if the actual API implementation conforms to that contract. Making sure that your API contract is good enough and there are no discrepancies between the design and implementation before protecting your API saves you from nasty surprises later on.

Before you start with API Protection, make sure you have audited and improved the quality of your OpenAPI definition with API Security Audit. For best results, we also recommend scanning your API with API Conformance Scan to ensure that the API implementation indeed matches the defined contract and that the contract properly describes all potential API responses.

Security as code

The purpose of 42Crunch Platform is to make security teams and developers work together. The developers know how to create an efficient service, but not necessarily how to best protect it. The security team knows how to secure a service, but not necessarily how to create one. 42Crunch Platform provides the means to integrate the expertise of both together in a consistent and persistent manner.

API Protection applies security directly into the API definitions themselves through x-42c vendor extensions to the OAS. These extensions are added directly to the OpenAPI definitions and they describe the security measures that API Firewall applies to the APIs it protects. This ensures that the vital information on the nature of the security the API requires is retained within the API and always follows it. Security is part of the source code of the API, not a separate afterthought.

This empowers developers to take part in defining API security. Because developers know what their APIs are and are not supposed to do, they are best placed to apply the required security measures to their APIs as needed. This can be done either in their editor of choice, or in Security Editor in 42Crunch Platform.

This does not mean that the security team is out of work: they are still the ones who know what kind of security measures are needed depending on the sensitivity of the API operations and the data they use as well as the line of business. Based on this, the security team defines protection strategies to cover the required security measures. Developers then add these strategies to the API definitions, and API Protection takes care of the technical application of security.

The security information in API definition is only for API Firewall and only used on the server side. Your API consumers do not have to consume it.

For more details, see Protections and security extensions.