Questions Answered: The Anatomy of Four API Breaches

You had questions, and we’ve got answers!

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.

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…