Securing Android Application API access

Question

While creating an Android App that uses an API, the most difficult problem to solve is API security.

Creating a token and securing it in KeyStores is one thing. But what about a guest user?

A guest user requires a Token, and acquiring that Token from the API is not secure, as this API should not require any signing credentials. And creating a temporary Token for the guest user in the Application side is not secure as anything on the Application or Device is accessible one way or another.

I have searched about the thing, and these are the solutions I've found.

1. Creating a 2-part key : This is not secure, as there is still something on the Application side.
2. Google's Application authorization : I've found that there is a way to use Google's services to determine whether this client (Application or whoever sent the request) is a valid (legitimate) user, i.e, the request was sent from the Application for which the API was designed for. However, I've seen that this method requires waiting, as the validation is not immediate.
3. SSL Pinning : I'm not very familiar with the concept, but from what I understand, it's basically creating a Certificate that only your app and the server trust. But that seems to also put code (or in this case, a .crt file) in the app package, which can be compromised and used.

I understand that there are tactics such as ProGuard and DexGuard, but these only make it harder for someone to break into your app, and in DexGuard's case, it's paid.

I thought about using the API to identify that only the client is the app using the package name, but that's not possible since the HTTP/S Client requesting the API is not the app, it's the system's, or in some cases the library's, own HTTP/S Client implementation, which does not contain any information about the app, only the system/client.

From my understanding of application security, these are the main security flaws to be noticed :

1. Anything inside the application code, files, or resources can be accessed using the APK or the application's own folders on the system.
2. Even HTTPS SSL certified requests can be sniffed and the attacker can obtain all information about the API (URL, Parameters, etc).
3. Even if something was protected by the system (such as files), rooted/hacked devices can get access to these resources (there are also legitimate reasons to root your Android device, which means you cannot just block rooted devices).

Searching around in Information Security questions most focus about the Android system's security, not the security between an App and it's API. And the few that do, discuss the security from the server's side, or simply give an example about using a certain technology (Certificate Pinning or Certificate Transparency) in plain code, which is still not secure.

Question :

What are the tactics used to protect an Application from an attacker?

What methods should I be researching to make 95-99% sure my application won't be attacked (there is no 100%, I know, but that 1-5% are dedicated attackers, which wouldn't waste time on such applications from a less known provider)

Possible Attack :

The App has a guest user, meaning they need a temporary Token to use the app. This token cannot be generated from the API, as it does not require any authorization. And cannot be generated from the App since breaking the application code is simple and the attacker can discover the method of generating a temporary Token.

This leads the the API and Application being exposed to the attacker, giving them access to the API's data.

Answer 1

I wanted to comment on your question, but I don't have enough reputation for that. You're discussing various things surrounding API and application security. Maybe this article: https://dev.to/bearer/api-security-best-practices-3gjl could gives you some insights. If you apply these practices you should be pretty good.

Like you said, you can't be 100% safe and you have to weigh the risks. Most companies accept certain risks.

Answer 2

As @Domen's comment says, you need to specify your threat model, including what resources you're trying to protect. However, there are a few general notes you should consider.

1. For most practical purposes, you CAN'T prevent third-party clients (whether they be mobile apps or not) from using your API, and you shouldn't even try. You bring up YouTube as an example, so I'll do the same: anybody can write (and many people have written) YouTube clients for various platforms with various official or unofficial features, plus it's available via the web and via anything that can make HTTPS requests.
2. You talk about Guest users a lot, but you haven't even specified what the meaningful difference between a guest user and an authenticated user is. If the API has some need for accounts at all (e.g. it's expensive to fulfill requests, so you need to know who to charge), then reconsider whether you want to allow unauthenticated access at all (you can still have trial periods, although if the trial is too good then some people will just start a new one when one ends). If it's more like YouTube, where passive consumption is public and ~free, then you can just have the server assign a guest token to anybody who shows up with no token and doesn't log in. Yes, the token will be stored on the phone where a determined user could extract or replace it, but so what? It isn't tied to anything meaningful; it's more akin to a tracking cookie so you can tell John Doe and Jane Doe apart.
3. If your API is something where it's important to keep users distinct (e.g. because it's a task-tracking app and they might upload sensitive data) but you still want to allow using the app without an account creation step, do an implicit account creation and store the account's login token in the client. Again, a sufficiently determined user could extract it, but if they do so, then either they are trying to get at their own token for their own uses (perhaps to copy it to another device because they're changing phones) and you should just let them, or they're an attacker breaking the OS security model to steal data that is private to apps (and there's nothing you can do about the risk that a user's OS is insecure).
4. Speaking of OS security, just trust it. It's not perfect, and for extremely sensitive data you can optionally add your own layer of security such as requiring a passcode on app launch and encrypting data with a key derived from that passcode, but it's good enough. The tiny fraction of users who root their devices and then don't secure the root access path (e.g. leave the default SSH password) might get compromised, but this is not your problem; they did it to themselves and you neither can stop this, nor should expend effort on trying (e.g. "root detection" is mostly a waste of time, except possibly to just notify the user that their security is in their own hands).
5. The user is not the attacker. If your API and/or app require keeping any secret from legitimate users, your entire security model is hopeless and you should find something else to do. This way lays DRM, defective by design and fundamentally impossible to make truly secure; if you really feel it's needed for some reason, some obfuscation snake-oil salesman will happily take your money, and perhaps buy you whole days of time before a dedicated reverse engineer breaks it. This ties back to point #1 above, of course; anything that you could use to prevent the "wrong" client from accessing your API is user-hostile, and users can circumvent it (whether they will or not is mostly a matter of whether they care enough to do so).
6. Actual API security is things like authentication, authorization, session management, transport security, preventing server-side injection attacks (SQLi, command injection, LDAP injection, whatever), deserialization/XML/other data format attacks where a malicious request will make the parser do the wrong thing before the API server even actually processes the request body, denial of service, and so on. It's a strict subset of web security, so anything that could be done in a web app can be done with a non-web API client, but it doesn't meaningfully enable additional scenarios (aside from zero-trust security models, where webapps break down because the code must be loaded from the untrusted server every time). Unless you're trying to build something like Signal or another end-to-end encrypted platform, if you can do it using an API, you can do it in a web app too (there are just more security risks to consider, like XSS).

If you want more specific advice about how to mitigate a particular threat, you will have to provide more specific information about that threat. Also, though, somebody has probably already answered that question; make sure you search before asking.

Answer 3

Let me try to sum your situation up and then try to provide my insights.

You have created an app, which uses a backend API to retrieve and store information on a server/database. The API is only meant to be used by the app and shouldn't be accessible/usable by the end user. If this is the case, I see two options:

1. You either authenticate the users and use the login details to access the API from the app, which then enables the user to use the API without the app, or
2. You change the design of your business model so that it doesn't need an API at all. The whole point of the API is to expose functionality to the public to support your business model, whether it is through your app or otherwise. If the information and functionality are only to be used by your app, then I don't see any reason to have an API in the first place.

Now, I will pre-emptively agree with you that having an API enables you to run analytics and potentially create more apps, interface with other systems and so on. However, the complexity of your problem and ultimately your big question is this:

What comes first, protecting the information or enabling the user by providing the information?

I'll too use YouTube in this context. YouTube's monetary gains are not from the content itself. Sure, there is paid content etc, but the majority of the information is public. Most of the money are made through advertising.