For a little project I want to send push notifications directly from the app (without a backend).
As I read from the FCM documentation while this is technically possible with a simple HTTP POST request it's discouraged because in this way I have to hard-code the server key that will become easily retrievable with a little of reverse engineering.
So I though to add my server key in the Firebase remote configuration and use that.
What do you think? Are there some contraindications?
Thank you very much.
Storing the key in Firebase Remote Config doesn't make the approach secure. After all: the app still needs to be able to access the key and thus remote config.
Any solution that uses the server key in the client-side code is susceptible to abuse.
Related
Right now I have my Server Key for Firebase messaging hardcoded in my code.
Is this a security problem for when I deploy my app?
Can I get this key programatically?
Yes it's a security issue,according to this official document at the bottom says.
Important: Do not include the server key anywhere in your client code. Also, make sure to use only server keys to authorize your app server. Android, iOS, and browser keys are rejected by FCM.
And I don't think "get this key programmatically" is good idea because you still downloaded key to the client,or using other way to store in the client.
There's no way to protect in a serious way the key in your apk. Getting the key would be quite easy, so you have a big security issue and your poor security design could have bad conseguences, see for example what GDPR says about privacy. Remove the key, change it if possible and implement a server to communicate with your clients and send push messages.
What I want is to perform rest requests to Firebase Realtime Database from my esp8266 with micropython firmware without complex authorization process.
I know that I can turn off authorization at all in the rules but I'd prefer to have at least some basic security.
Can't I just use my Web API Key for this purpose?
Here is a doc which tells that there are 2 ways of authentication: oauth2 and generating key manually. Second way seems almost what I need but it requires setting up Admin SDK and as far as I understood still requires regenerating the key from time to time.
So eventually I have no answer to a simple question: how to authenticate rest requests to the Firebase Realtime Database in the most simple way?
The same page you linked to contains a section on using legacy tokens (also known as "database secrets" in the past). While those are not recommended anymore, they continue to work and are as simply as adding the (non-dynamic) database secret to your URLs.
I suggest you read the links at the bottom of the documentation. But I do recommend that you switch to using the OAuth or ID Token flows as those are much more secure.
Is it recommended to manage users in the client side or in the server side?
I'm worried about the authentication that has to be done in the client side if I manage the users in the client side.
Yes, you should manage user data on the server. Firebase already provides facilities for this: https://firebase.google.com/docs/auth/users
I run at the same problem it seems that Java server side API in firebase-admin JAR lacks these methods.
Red line in documentation https://firebase.google.com/docs/auth/admin/manage-users confirms that :(
In an interesting blogpost about 'Firebase Authentication with the Firebase 3.0 SDK and Auth0 Integration', it is stated that:
You can even have Firebase communicate with Webtask!
Now I can imagine the (web)client triggering a Firebase operation and subsequently a Webtask, but not the other way around. Or am I missing something?
Firebase can run as a serverless app, but it can also run on the server. You can even have Firebase communicate with Webtask! (sic!)
I think that paragraph is misleadingly phrased, perhaps it was just added at the last minute to spark interest. You can have a webtask communicate with Firebase, not the other way around. You don't "run Firebase" on your server either.
TL;DR: A client application may call a webtask with an HTTP request, and that task can read/write the database, but not in any other order.
Here's a quick and dirty reality check as of Nov. 2016:
The Realtime Database by itself does not provide you with a way of executing code. This includes responding to database changes and user requests, handling fan-in and fan-out operations, etc. There is no support for webhooks either.
Which means you have to provide your own execution environment for such logic on a custom server, or you can try to cram as much as possible into the client code. This is a pretty exhaustive topic by itself.
Webtasks are short-lived functions that respond to HTTP requests. Their lifecycle always starts with a request, so they are not fit for continuously watching the database for changes. But they are perfectly valid for handling requests coming in from your client application.
As you can store "secrets" for the webtasks, you can authenticate the task on an admin access level. This gives you the possibility to verify client tokens – which should be sent along with the request –; perform complex authorization and validation, and perform RTDB write operations you wouldn't trust the clients with.
Or trigger external services securely. The possibilities are close to endless.
Can somebody else get the Firebase credentials from my APK and use them? Is this prevented by adding the SHA-1 keys for Android?
If it is prevented, what do I need security rules for since only code from my app with my SHA-1 can manipulate database at all?
If it is not prevented, can somebody else use my Firebase database as long as his requests fit the security rules? (Write 2nd client, which actually cannot do bad things but should not be allowed at all.)
Im not sure how I should think about security rules:
A) Protecting data against access and manipulation from bad guys + B?
B) Just a set of rules to keep data in a certain state and prevent my software from doing invalid database request?
A Firebase Database can be accessed via the REST API, or any of the client libraries. The decision about whether a client can or can't do something is entirely based on the rules.
You can even just access the Database URL in a web browser and see a JSON response by putting .json on the end, e.g. https://[YOUR_PROJECT_ID].firebaseio.com/.json
So the answer is definitely B! The default rules in a new Firebase project are that read and write to the database require auth, but you can configure them to provide whatever levels of protection you need.
Take a look at the Database Rules quickstart to see what you can do!
We don't ship the Realtime Database secret (or any other "secret" material) in the json file that gets baked into your app. That file simply contains resource identifiers that allow us to know which resources (database, storage bucket, analytics, etc.) to properly authenticate to (we use Firebase Authentication for these purposes), and we handle server side authorization to ensure that users are properly logged in.
If you are authorizing your requests properly (using Firebase Realtime Database Rules, for instance), your data is secure!
I'd recommend watching The Key to Firebase Security, one of our I/O talks, which talks in greater detail about how this works.
firebaser here
Thanks to the new feature called Firebase App Check, it is now actually possible to limit calls to your Realtime Database to only those coming from iOS, Android and Web apps that are registered in your Firebase project.
You'll typically want to combine this with the user authentication based security that Mike and Ian describe in their answers, so that you have another shield against abusive users that do use your app.