On API Resilience

Last week, I published an article on API Security. It discusses how to combine mobile RASP with API Security. One valuable feedback I got was to remove the word "security" and replace it with "resilience". This makes a lot of sense, especially for those that are coming from the API security world. The field addresses security elements related to APIs. This includes authorization, access, DDoS, SQL injection protection, etc. This should be the Gold standard when it comes to API security. There is even a dedicated OWASP project for it.

All mobile apps should build on top of these standards and adhere to security controls defined in the OWASP project. However, mobile apps have additional security requirements. The goal of mobile malwares (Especially financial-oriented ones) is to siphon out funds from customers. All the twists and turns about exploit, vulnerability boils down to making these transfers from the user's device. This action is directly connected to API endpoints that talk to the bank's backend. So it's only natural to strengthen it.

Consider this layered approach. One starts with bare-bone API and then adds OWASP API security controls on top (or Preferably builds APIs with these security controls in mind). Based on your risk profile, you might add more blocks to strengthen it. Defense-in-depth strategy. The last "API Resilience" block is about increasing the difficulty level for an attacker thereby reducing the chance of compromised devices from accessing your server endpoints.

While this sounds straightforward, implementing it is not. Here are a few technical and somewhat business requirements that need addressing

1. "Security" Vs "Resilience" - The term "security" might be misleading for some folks (even customers). What happens if you want to secure your mobile API endpoint? Can you add specific controls to strengthen it? Would this addition be called security? Or would you call it hardening/resilience? The semantics is important because it can confuse many people in the industry. I don't have an answer. But something to think about
2. WAF Integration - Part of fully automating RASP & API security is to have it built inside WAF. What happens if a customer is using WAF that doesn't support token verification or doesn't allow some kind of integration point? This would mean deploying mobile specific WFA into the customer's env't. This might not go well with some customers. Otherwise, manual setup is required - a scenario we are trying to avoid
3. SDK Integration - The complexities of building zero-touch RASP is challenging. This compounds when considering the ever-changing framework landscape. Flutter, React, Xamarin, Cordova, etc. I don't think it will be possible to address all of them; especially those that are older

Some of these questions might not have a right or wrong answer. They're theoretical questions that might not add much value to the overall ecosystem. The only way to verify them is to build a small POC and see where it goes.

Let's see

Cheers