Questions Answered: The Anatomy of Four API Breaches

You had questions, and we’ve got answers!

Thank you for all the questions submitted on our “The Anatomy of Four API Breaches” webinar. 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.


Dissecting the Anatomy of 
Four API Breaches

Watch Webinar

The Anatomy of Four API 
Breaches Slide Deck



Does the implementation of OAuth2 mitigate the risks you mentioned?

OAuth2 is one of the tools you need to use, among many others. OAuth2 only covers the API authorization aspects (who has the right to access a given resource). OpenID Connect is a complementary standard to OAuth2 that will cover the authentication aspects (https://openid.net/connect/faq/).

OAuth2 is not enough because it does not cover any of the cases related to mass assignment, data leakage, etc. Somebody with a valid token could still abuse the API. 

Also, one key aspect to remember is that OAuth2 is a framework that needs to be adapted based on your usage (the risk factor we mentioned in the webinar).  The Financial grade OAuth profiles are a great example of how to properly use OAuth for sensitive APIs https://openid.net/wg/fapi/.

If you’re confused about which OAuth2 profile to use, check this: https://aaronparecki.com/oauth-2-simplified/. In a nutshell, using the authorization_code grant type flow is the recommended best practice for single page Apps, mobile apps, and web apps.


Are there any open source tools for fuzzing APIs – for hammering it with bad data, which can be used in an automated way?

OWASP Zap is the most known one, but it has limited support for specific API attacks. 

Yelp has also released a fuzzing tool here: https://github.com/Yelp/fuzz-lightyear, geared towards BOLA/IDOR issues.

At 42Crunch, we have a conformance tool that helps you ensure automatically that your implementation is in line with the contract you supplied. The tool injects all kinds of incorrect data into requests to prove how your API reacts when hammered with bad data.


For the most part, would you consider mTLS (Mutual TLS) as required to secure API endpoints, or optional?

MTLS is certainly an option if you know who you’re going to interact with, your own apps or known partners for example. MutualTLS does come with an administration cost though (issuing the client certs, which needs to be governed properly, renewed, revoked, etc.).

You should also look at certificate pinning for additional TLS security: (https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning


What about Kali Linux? Does this test APIs?

Kali Linux is a platform with pre-installed tools for security testing, although many of them are geared towards traditional web applications testing. OWASP Zap is one of them.


Do you have a partnership with Qualys? any plans to include any of these checks in their products?

We do and Qualys introduced their new API Security products at their QSC earlier this year. Check Dave Ferguson (Product Manager @Qualys) presentation here: https://www.qualys.com/docs/2020/qsc/san-francisco/qsc20-sf-api-security.pdf


When you are using an API from a vendor that you rely on for your own security, what do you recommend to best secure yourself? Should you pen test yourself, or should the vendor share what testing they have done?

Legally, you can’t pen test something which is not yours. So, yes you need to ask the vendor how they tested security on their APIs. You could start by testing the OpenAPI/Swagger file they gave you in our platform though! Zero risk to break anything…


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