Skip to content

Open Source API Firewall by Wallarm Black Hat Arsenal USA 2022

API Firewall is a high-performance proxy with API request and response validation based on OpenAPI and GraphQL schemas. It is designed to protect REST and GraphQL API endpoints in cloud-native environments. API Firewall provides API hardening with the use of a positive security model allowing calls that match a predefined API specification for requests and responses, while rejecting everything else.

The key features of API Firewall are:

  • Secure REST and GraphQL API endpoints by blocking malicious requests

  • Stop API data breaches by blocking malformed API responses

  • Discover Shadow API endpoints

  • Validate JWT access tokens for OAuth 2.0 protocol-based authentication

  • Denylist compromised API tokens, keys, and Cookies

The product is open source, available at DockerHub and already got 1 billion (!!!) pulls. To support this project, you can star the repository.

Operating modes

Wallarm API Firewall offers several operating modes:

  • PROXY: validates HTTP requests and responses against OpenAPI 3.0 and proxies matching requests to the backend.

  • API: validates individual requests against OpenAPI 3.0 without further proxying.

  • graphql: validates HTTP and WebSocket requests against GraphQL schema and proxies matching requests to the backend.

Use cases

Running in blocking mode

  • Block malicious requests that do not match the specification

  • Block malformed API responses to stop data breaches and sensitive information exposure

Running in monitoring mode

  • Discover Shadow APIs and undocumented API endpoints

  • Log malformed requests and responses that do not match the specification

API schema validation and positive security model

When starting API Firewall, you should provide the REST or GraphQL API specification of the application to be protected with API Firewall. The started API Firewall will operate as a reverse proxy and validate whether requests and responses match the schema defined in the specification.

The traffic that does not match the schema will be logged using the STDOUT and STDERR Docker services or blocked (depending on the configured API Firewall operation mode). When operating in the logging mode on REST API, API Firewall also logs so-called shadow API endpoints, those that are not covered in API specification but respond to requests (except for endpoints returning the code 404).

API Firewall scheme

By allowing you to set the traffic requirements with the API specification, API Firewall relies on a positive security model.

Technical data

API Firewall works as a reverse proxy with a built-in OpenAPI 3.0 or GraphQL request and response validator. It is written in Golang and using fasthttp proxy. The project is optimized for extreme performance and near-zero added latency.

Starting API Firewall

To download, install, and start API Firewall on Docker, refer to:


You can try API Firewall by running the demo environment that deploys an example application protected with API Firewall. There are two available demo environments:


When creating API Firewall, we prioritized speed and efficiency to ensure that our customers would have the fastest APIs possible. Our latest tests demonstrate that the average time required for API Firewall to process one request is 1.339 ms which is 66% faster than Nginx:

API Firewall 0.6.2 with JSON validation

$ ab -c 200 -n 10000 -p ./large.json -T application/json

Requests per second:    13005.81 [#/sec] (mean)
Time per request:       15.378 [ms] (mean)
Time per request:       0.077 [ms] (mean, across all concurrent requests)

NGINX 1.18.0 without JSON validation

$ ab -c 200 -n 10000 -p ./large.json -T application/json

Requests per second:    7887.76 [#/sec] (mean)
Time per request:       25.356 [ms] (mean)
Time per request:       0.127 [ms] (mean, across all concurrent requests)

These performance results are not the only ones we have got during API Firewall testing. Other results along with the methods used to improve API Firewall performance are described in this Wallarm's blog article.