Questions Answered: Protecting Microservices APIs with 42Crunch API Firewall

You had questions, and we’ve got answers!

Thank you for all the questions submitted on our “Protecting Microservices APIs with 42Crunch API Firewall” webinar. Below are all the answers to the questions that were asked. If you’d like more information please feel free to contact us.


Protecting Microservices 
with 42Crunch API Firewall

Watch Webinar

Protecting Microservices 
APIs Slide Deck




Can the sidecar be tested somehow?

Yes, the configuration is tested before it is made available to the API FW. Note that sidecar is only one of the form factors: nothing prevents you from deploying the runtime locally in Docker for example for testing purposes.


Can you share more information on your sidecar?

Our sidecar API firewall is a lean runtime, of about 20 megs in size, that consumes natively an OAS file to use it as an allowlist. It has been optimized to only incur minimal latency: recent performance tests show a 1-3 ms latency with 2500 TPS, with payloads varying from 3 to 16kb. Remember that we validate both requests and responses.


Do you have 100% coverage of the OWASP API Top 10?  

Our solution will help you protect yourself from the OWASP Top10 list of API threats at AppSec level, but as I mentioned during the call, you need to be careful about these across all the layers of your deployment. For example, we have taken great care about the security architecture of our platform and runtime. But you have to do the same in your application, for example making sure your application does not use libraries/frameworks with known CVEs.


Oh and what if we don’t have a swagger definition?

We require a OAS/Swagger file, since this is the base for our allowlist.


Our App team is already using envoy sidecar proxy to offload encryption. Can your solution co-exist to provide API Security?

Yes, that is totally feasible. Envoy does the infrastructure security and we do the AppSec security.


Any new feature coming up that also scans for unmonitored/unregistered (shadow) APIs?

We will report unknown APIs already – Since we could typically sit in the line of traffic (deployed in proxy mode instead of sidecar mode), we would see and block any unknown requests and report them. 


If the API contract is not available (say developers do not maintain or its outdated) how does that work?

We highly recommend to deploy our FW as early as dev time. This way, such discrepancies will be detected early in the API lifecycle. Unknown requests will be reported/blocked, providing instant visibility in any disconnect between the actual API and the contract. 


do you have pre-configured template for Kubernetes Admin API?

We do not have a Kubernetes operator available yet. This is something on the roadmap. 


Is any language supported for developing policies-as-code or is it only OpenAPI translated policies?

The allowlist aspects are done through the standard OpenAPI specs. However, this language can be enriched with our own annotations, in order to engage additional protections such as security headers injection, bot protection or JWT validation. 


Do you reapply policies dynamically? How is caching for policies on the sidecar managed?

The API FW configuration is retrieved at start time from our SaaS platform then kept in memory. If a new configuration is made available centrally, you can use our UI or our REST API to instruct the FW to gracefully restart.


Try our security audit for free. If you want to see the whole platform in action, request a demo now!