Client Side app <--> Backend <--> API
Is this the correct way for secure API by accessing from other client side apps? If it is, Why we need API? We can directly use Backend to fetch and process data and then send back to client. Could you please explain this?
Note:
What I meant by above simple diagram is, Client side app make request to backend and then backend makes requests to API.
CodePudding user response：
You can't protect an API from other client side apps. Any magic thing you send in the request that means "Hey I'm authorized" would have to be part of the app, in which case it can be reverse engineered. What you can do is authorize a user- the user can log in via some secret (such as a username and password), and the server can send back a secret code in response, that the client will send back in later requests. That secret code will be different for every user. Do that, and do it over an encrypted connection (HTTPS) and that's about as good as you can do on that front (there's minor details like expiring old codes and rotating them, but they're all implementation details around this idea).
The reason why you can authorize a user and not an app is that the user holds a secret that someone decompiling an app can't get, because it's not in there- it's in the user's head. Without that, there's no way to know if an app is really authorized or if someone decompiled and stole your secret.
CodePudding user response：
Your Problem
What I meant by above simple diagram is, Client side app make request to backend and then backend makes requests to API.
It seems to me that you are a little confused with the terminology being used, because an API server is in fact a backend.
I think what you mean by the use of this:
Client Side app <--> Backend <--> API
is this:
Client Side app <--> Reverse proxy <--> API
Reverse Proxy
The traditional approach used to reduced the number of API keys in a mobile app is the use of a Reverse proxy, but it only makes sense if your app makes requests to two or more APIs, because you will always need an API key to make requests to the Reverse Proxy.
Reverse Proxy is more commonly used to protect access to Third Party APIs, and I wrote the article Using a Reverse Proxy to Protect Third Party APIs that goes in more detail why you should use it:
In this article you will start by learning what Third Party APIs are, and why you shouldn’t access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.
The use of a Reverse Proxy only shifts the need from protecting the API key for the third party service, or your own API backends, to protect the API key or any other secret/identifier used to access the Reverse Proxy, but with the advantage that you now have control of how the third party API can be accessed, while keeping the API key to access them out of reach of the mobile app attacker. In other words you only expose one API key in your mobile app, thus reducing the attack surface, with the added benefit of having one single place where you can mitigate the abuse of using your API backends.
The Difference Between WHO and WHAT is Accessing the API Server
Before I link you to some possible solutions I would like to first clear a misconception that usually I find among developers of any seniority, that is about the difference between who and what is accessing an API server.
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
When you grasp this idea and it's ingrained in your mindset, then you will look into to mobile API security with another perspective and be able to see attack surfaces that you never though they existed before.
Possible Solutions
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
Your best option to lock the API backend to your Mobile App is to use a Mobile APP Attestation solution that will give a very high degree of confidence to the API backend that the request is originated indeed from a genuine and untampered version of your mobile app.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.