I have an application that connects to firebase cloud storage to store images and firestore to store data. I have added some security rules that require the user to be authenticated to be able to modify the data. My application doesn't allow users to connect with firebase, I use another service so I made an automatic anonymous firebase authentication at the launch of the app so that users can use the application. I thought that the computer's SHA-1 key entered in the firebase(android) console would prevent the android application from being compiled on another machine and thus guarantee that anonymous users are on my application. However I can build and run the application on another computer without any problem, as if anonymous allowed that? How do I secure my application?
Thanks
The configuration data used by Firebase to find your project on the servers is not a secret (see here) and can be taken from your app by anyone and then used to also make API calls against your project. There is currently now way to ensure calls to the API can only come from your app (see here).
What you instead should do is create security rules that ensure all access is authorized, no matter where the API is called from. Doing this through Firebase's server-side security rules ensures that no one can bypass these rules, not even a malicious user.
Say that you give each user their own folder in Firebase Storage. You can then use security rules to ensure each user can only read and write files in their own folder. And with those security rules in place, it doesn't matter anymore whether they use your app to access the files, or whether they call the API with your project keys and their own code:, since the access is controlled by the server-side security rules.
I thought that the computer's RSA key entered in the firebase(android) console would prevent the android application from being compiled on another machine and thus guarantee that anonymous users are on my application.
That's not really the way it works. You can't restrict Firebase Auth from working on different devices or computers. The underlying REST APIs are public and can be called from anywhere on the internet. The SHA-1 key that you enter in the console is intended to identify your app, not a piece of hardware.
Related
I have the following mobile app scenario based on a Firebase backend:
Two or more mobile app instances communicate with each other through a central service (trusted). The apps are paired by exchanging a shared secret, e.g. through scanning a QR code or entering a pairing code.
Users are anonymous, ie no signup required (or possible). Essentially, it is the specific app on a specific device that is paired with a ditto counterpart (vs user-to-user).
Information exchanged is sensitive but has no intrinsic value: It must be possible to trust that information comes from a given device and it must be possible to trust that the information has reached the intended device and not an impersonating device. But it is not a critical problem that an app instance's information is lost, e.g. if the app is removed or the device is destroyed (an annoyance that requires re-pairing, but not a critical issue).
It seems Firebase Anonymous Auth is a perfect match for this scenario - but the documentation hints that it should only be used as a temporary solution until users create an actual account. Are there any drawbacks to using anonymous auth as the sole authentication method for the solution? The alternatives I see are some kind of hack using a custom token-based login or perhaps email/password auth.
Are there any drawbacks to using anonymous auth as the sole authentication method for the solution?
There isn't unless the user uninstalls the app.
The documentation hints that it should only be used as a temporary solution until users create an actual account.
Why a temporary solution? It's because anonymous accounts do not persist across application uninstalls. If a user uninstalls the app, everything that was saved locally will be deleted, including the anonymous auth token that identifies that account. Unfortunately, there is no way to reclaim that token for the user.
The alternatives I see are some kind of hack using a custom token-based login or perhaps email/password auth.
IMHO, the best approach would be to use anonymous authentication but to also let the user the possibility to link their account with email and password or any other providers, like Google, Facebook, Instagram, and so on.
I am the owner of the Firebase project.
Is it possible (for accidental data manipulation reasons) to disable write access from Firestor DB?
For instance when login in the web admin console e.g.
https://console.firebase.google.com/u/0/project/MYPROJECTID/database/firestore
to not be able to write/update/delete any documents or collections.
If you want to disable write access to web and mobile clients, you can set the security rules to disallow all writes. There is no other configuration to control client access.
For backend code, and collaborators accessing the database through the Firebase console, you can only revoke access to any services accounts that might be used to make changes using IAM.
I developed two different Flutter applications. An Admin Version and another Client Version. I would like to use the same login (auth) and access to Storage for both Apps.
It's definitely possible to access the same Firebase project from two different apps. In fact, when these apps are locally part of the same "application", that is actually an intended use-case.
A few things to keep in mind though:
Firebase Authentication does not have the concept of an administrator user. It "merely" authenticates the user, allowing them to sign in with their credentials. Any administrator logic is specific to your application, hence often referred to as an application administrator. You'll typically want to flag application administrators, for example by setting a custom claim on their accounts.
Not all functionality that the application administrator may need is going to be available in Firebase's client-side SDKs. A common scenario is that the administrator should be able to create accounts for other users, where the client-side Firebase Authentication SDKs don't support this logic. For some more information on this, and how to solve it, see Firebase kicks out current user and my answer with many links here How to create firebase admin user for authentication in java. In a nutshell: you'll have to use the Firebase Admin SDK, in a trusted environment, for some of these operations.
You then secure access to Cloud Storage by writing security rules. For some examples of securing access based on the user, see the documentation on securing user data.
I have a firebase web app calling my Python API.
the user who is using my app does not need to login to use it but I still need to make sure that this request coming from my application
How can I verify the identity of the app sending the request?
There is no way to enforce that calls can only come from your application. In a database that is directly accessible from the internet, that is simply not possible. Anyone who can use your web app, can take the configuration data from that app and use the Firebase API to make their own calls.
That's why it's important that you enforce all business rules that you have for your database in Firebase's server-side security rules too. You can use these to enforce data structure, and (when combined with Firebase Authentication) ensure that all data access is authorized.
You can use Firebase Authentication without requiring your users to enter credentials by using anonymous authentication. This essentially gives your user a unique ID, that you can then use to identify that user (and the data they create) in security rules.
I’m coding a Firebase application.
The user can only read the database and the owner can write in the database to add some content.
The owner would need an admin desktop application to upload data on the database (storage and database).
Since the application is a C++ app I would use python to communicate with Firebase.
I wanted to use Pyrebase or python-firebase but unfortunately these projects seems not to support the new database Firestore…
The rest API could work but... only with the Firestore database part...
My only way to add content to Firestore and storage is then to use the admin sdk.
I know that the C++ applicaiton will be used only on the owner computer but I’m worried about getting the service account file.
What would be the best way to use safely the service account file?
I thought to:
Encrypt the file with a password and then ask the password every
time the c++ needs to use the admin sdk (which technology would be
better for this?)
Download the service account file everytime the app needs (but where
to store it safely in the cloud?)
In order to use the Admin SDK with a project, you must have access to the service account credentials for that project. And with those credentials, you have full and unlimited access to the project. You should only distribute the service account credentials to users who should have such access, typically the collaborators on the project.
For application level administrators that are not collaborators on the project, I typically recommend setting up an administrative dashboard with a server-side and a client-side component.
The server-side component runs in a trusted environment, which for me often is Cloud Functions, but can also be a server you control, or even your development machine. This is where you use the Admin SDK to perform application administration actions, which you then expose in an authenticated end-point that client-side applications can call.
The client-side component is what the application administrator uses. For me this is often a very simple web page, but it can also be any other technology you prefer, as long as it can call the end points you exposed on the server.
The key here is that the server validates that the user that calls it is authorized to do so, before executing administrative actions on their behalf. With this approach, you don't have to give the service account credentials to a non-collaborator, and can revoke the administrator's credentials if needed.