BLOG

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.

 

[xyz-ihs snippet=”Anatomy-API-Breach”]

 

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…

 

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

Latest Resources

WEBINAR

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.

NEWS

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

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.