Questions Answered: OpenAPI for API Security

You had questions, and we’ve got answers!

Thank you for all the questions submitted on our webinar: “OpenAPI for API Security – Why guess when you know?!” Below is the replay and all the answers to the questions that were asked. If you’d like more information please feel free to contact us.


Just wondering how it differs from nginx with WAF being applied? Is it ML built in or something else?

We are not using ML at all  – We are using natively the OAS file to protect APIs, enforcing all the rules expressed naturally in the contract. The main difference with a typical WAF ( like the mod_security OSS WAF that NGinx -and many others – is using) is that they take a signature-based approach to detect requests that may contain an attack. We are taking an approach where we help developers and security define the contract and the security constraints in the OAS file, and then enforce that at runtime.


With audit can we ensure that a schema has validation rules and with runtime we can throw away validators? Wondering if there is an way to somehow enforce owner validation (e.g. only owner can delete its own article)

I would never recommend to throw away any validation you are already doing in your code or stop doing validation. But an approach like ours ensures that the validation is indeed done, in a coherent way across all our APIs, independently of how they are implemented.


Wondering if there is a plan around graphQL movement and what can be done in this field?

Very hot topic too, where we will have to take a slightly different approach: we can still enforce that the verb/path/headers are correct, but we need specific rules for graphQL validation around depth, complexity and of course the list of properties that can be used in graphQL queries. We are at the beginning of this, and watch for news as we will soon deliver something along those lines!


Please correct me if I’m wrong in case of spec first development it might be a tool for infosec guys to ensure some rules being applied without asking engineers to do something.

Indeed! One of the key aspects of defining a proper OpenAPI first is that everything can then derive from it: implementation, testing, documentation, mocks, and in our case security.


Is it possible to add API specific custom rules in the audit tool, (example: path should be in specific format like only two levels, should not have special path etc..)?

Custom rules are indeed one of the most requested features, should be for nomenclature or security perspectives. This is something we are evaluating now, and looking at Q4 for delivery.


Do you see any performance issues related with runtime incoming request checks?

That’s a valid concern – Which is why we have special IP in that domain to ensure we do not add more than a few ms (<1ms – 5 ms) latency to a transaction. Now, the good news is that if you are doing say JSON schema based validation of signed payloads in another gateway, we could actually make the whole transaction faster as you move that to our firewall…And as per our experience so far, make those API contracts 10x tighter and under control. So much better validation and faster.


If you are using a 3rd party OpenAPI (i.e. ServiceNow), how would you recommend auditing the API to better understand the security controls to integrate for your environment?

Definitely. Any 3rd party API has to give you a certain quality of service and insurance that they do a proper job to validate data and keep hackers at bay. Experience we have now is pretty consistent: if the JSON schemas in an OpenAPI file are loosely defined, chances are that there are no other, better defined, schemas anywhere, which implies the payload (request and responses) are poorly validated.


Will your approach work for severless models such as AWS API Gateway with Lambda code? (suppose api is swagger 3.0)?

Once exposed by the AWS API Gateway, we don’t see the difference between Lambda or else (similarly, we have done a POC with Functions on Azure).



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

Latest Resources


Webinar Series - Defending APIs with Jim Manico

Defending APIs with Jim Manico – Episode 1

Episode 1: Request Forgery on the Web – CSRF & SSRF

November 10, 2022 | 9am PST | 5pm BST

Join Jim Manico, CEO of Manicode and Colin Domoney from 42Crunch, as they deliver a 2-part webinar series to help developers better defend APIs.


42Crunch Announce OWASP Membership

42Crunch becomes a member of OWASP to Advance API Security 

By Newsdesk | November 14, 2022

November 14, 2022, San Francisco, CA –  42Crunch is pleased to announce our corporate membership of the Open Web Application Security Project (OWASP), a worldwide not-for-profit charitable organization focused on improving the security of software. At 42Crunch we have always been inspired by OWASP’s role as an enabler […]


Datasheet Cover Images P1-02

Product Datasheet Addressing API Security Challenges

APIs are the core building block of every enterprise’s digital strategy, yet they are also the number one attack surface for hackers. 42Crunch makes developers’ and security practitioners' lives easier by protecting APIs, with a platform that automates security into the API development pipeline and gives full oversight of security policy enforcement at every stage of the API lifecycle.

Ready to Learn More?

Developer-first solution for delivering API security as code.