Build your backend in the @pragdave style and you can have your web app not using an API, be it REST or GraphQL, and have the mobile app using the GraphQL or REST API. So, basically you will want to have a clear separation of code that is specific for web requests, from the one that is specific for API requests, and have both talking with a core that is agnostic from the transport layers being used to talk with the client, aka the web app or mobile app.
As someone who works in API security I can tell you that I would avoid as much as possible to use them from a browser, because in web apps you are better in terms of security by not using them.
APIs are very hard to truly secure, aka to lock-down only to clients you want to allow access to it, aka the clients you have coded, by other words genuine instances of your web app and mobile app. You can tell me that you use API-Keys or any other fancy mechanism, like HMAC, and I can tell you that all of them are not that hard to bypass by a de-terminated attacker.
So I have a question for you:
Do you know the difference between WHO and WHAT is communicating with your API server?
In my experience developers of any seniority are often not aware of this difference or they have a misleading understanding of it.
I recommend you to read this article I wrote where I explain it in detail, but it can be resumed as:
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.
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
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.
You can also look to other articles I wrote that go into detail about extracting API keys for reuse outside your mobile app:
TLDR:
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.
TLDR:
The range of open source tools available for reverse engineering is huge, and we really can’t scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
Using MobSF to reverse engineer an APK for a mobile app allows us to quickly extract an API key and also gives us a huge amount of information we can use to perform further analysis that may reveal more attack vectors into the mobile app and API server. It is not uncommon to also find secrets for accessing third part services among this info or in the decompiled source code that is available to download in smali and java formats.
The lesson here is that shipping your API key or any other secret in the mobile app code is like locking the door of your home but leaving the key under the mat!
Regarding web apps an attacker just needs to hit F12 and search for the API key and extract it to use it in automated attacks against your API.
I can continue and go more deep in other scenarios that can be used to attack your backend, but I don’t want to overwhelm you, but if you are interested in learning more about different scnerarios you can always look for my answers on the security questions at StackOverflow:
Tip: Just click in the security tag on my profile to see all my answers to security questions.