Questions Answered: OpenAPI for API Security

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).