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 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.
Many 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 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 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 (
- Undocumented error codes
- Undocumented schemas
- Undocumented query or path parameters
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
firstname.lastname@example.org@elysee.fr is rejected (unlike in the Tchap breach).
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 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 Contract Security Audit. For best results, we also recommend scanning your API with API Contract Conformance Scan to ensure that the API implementation indeed matches the defined contract and that the contract properly describes all potential API responses.