Firebase Database - Can the creator read & write with it being false? - firebase-realtime-database

I was wondering if the creator of the database could read and write regardless of it being both set to false?
{
"rules": {
".read": false,
".write": false
}
}
And if it is so that no one can read and write including the creator, how do I make it so that I can be the only one to read and write?

With security rules like the ones you're showing, all direct access from mobile and web clients is fully rejected, regardless of how the user is authenticated in your app.
However, all backend SDKs, especially the Firebase Admin SDK, that are initialized with a service account will always bypass security rules. This means that code running in Cloud Functions, for example, will not be affected. This account is not necessarily the "creator" of the database - it is just a Cloud IAM account that's added to the project.
The Firebase console also bypasses security rules.
This means you can write backend services and API endpoints that work with the database on the end user's behalf, without granting them any direct access to the data.
If you want only one specific user, Authenticated by Firebase, to be able to read and write the data from a web or mobile app, you will have to code that into your security rules using the given UID of the account.

Related

Firestore security rules to control access only from an app [duplicate]

This question already has answers here:
Locking down Firebase DB access to specific apps
(2 answers)
how to make sure only my own website (clientside code) can talk to Firebase backend?
(1 answer)
Closed last month.
I have a messaging app that uses firestore storage to store all attachments and realtime for all messages. I find myself with the problem that by default any user from the Internet can read data, in the case of storage, knowing the url, you access the file and in the case of realtime, the messages.
My idea is to propose two options to see which is viable:
I have an app registered as a project, can the rules be configured to only allow requests that come from that app? How would these rules be made in store and realtime?
It can be configured so that only users registered through the Authentication section have access to the storage and realtime information.
For this option two I have tried this rule:
allow read, write, delete: if request.auth != null;
But I can still consult the resource from the internet and the browser without obviously being a registered user in my app.
You can't configure the security rules to only allow access from your own application, but nowadays you can configure App Check to do precisely that and can be applied to both Cloud Firestore and Cloud Storage.
App Check is not a guarantee though, so you'll still want to implement your security rules so that they only allow valid operations. How to do that is pure business logic of your application, so only you can determine how to implement - similar to how you implemented that business logic in the source code of your iOS app.
Also see:
Is it safe to expose Firebase apiKey to the public?
Locking down Firebase DB access to specific apps

Can a device be blocked from accessing an application based on its FirebaseAuthentication ID?

If I notice fraudulent activity on my application by an authenticated user (by Firebase Authentication), can I block the device associated with this user so that he can no longer access my application? And if so, how do I do it?
Thanks for your attention !
A Firebase Authentication user has a UID, that you can use to allow them to access certain resources. To block a specific user from Firebase Authentication itself, you can disable their account. So don't delete it (as they can just recreate it in that case), but disable it. After doing that, they won't be able to sign in, and will be unable to refresh their ID token (which happens hourly).
If you use one of the Firebase databases (Cloud Firestore, or Realtime Database), you can also implement a list of banned UIDs in there, and then check against that in your security rules.

Is there a way to default disable users in a firebase authencation on signup?

I am currently developing an iOS appplication using xcode and Swift. My application works well with firebase including the function of email verification. Due to the nature of my application, I want users to be able to sign up, verify their email and then await further verification on the side of my client using firebase.
In an ideal world, firebase would have a setting that supports user being automatically disabled on signup, and you would just tick a box and the user would be enabled in the authencation page of the console.
Seeming as I am looking for my client to be able to do this, I need a way that is simple to them, so they can enable and disable accounts. There is a property in the firebase authencation page but no way to default it.
So.. My idea was to create a cloud function in firebase that automatically disables users on signup, and once my client has verified who they are they will enable them. Any ideas on what this function would look like? Disabled is a nice and easy boolean value so.
I am new to firebase, so wondering if anyone had came across this kind of issue? The link below shows the function on user creation.
https://firebase.google.com/docs/functions/auth-events#trigger_a_function_on_user_creation
You can add an Admin SDK function in the user creation event you have. See this for an example: https://firebase.google.com/docs/auth/admin/manage-users#update_a_user
The easiest way to automatically disable new user accounts is through Cloud Functions. See for an example the answer to this question about How to prevent new user registration on Firebase?.
But note that the user will already be signed in by the time the Cloud Function runs, so they'll have access until their current/initial ID token expired (up to an hour).
The proper solution is to check whether the user is verified before enabling any backend functionality. For Cloud Firestore, Cloud Storage, and Firebase Realtime Database, you can do this in their server-side security rules. See for some examples of this:
(Firebase) Firestore security rules - allow if email verified without custom tokens?
Security rule to only allow write for users with verified emails
How do I lock down Firebase Database to any user from a specific (email) domain?

"Copy this file to your authentication server" - Firebase Custom auth

My goal is to prevent users of multiple login in. I do not want this to be client-side, with like the onDisconnect and onConnect values, but with a server check. I came across this answer:
How to prevent simultaneous logins of the same user with Firebase?
Which tells me to create a custom auth system. When I am following the docs (https://firebase.google.com/docs/auth/ios/custom-auth) I need to "Copy this file to your authentication server" (3c). How would I do this? I am just using Firebase and my little iOS app. I would like to manage everything on these 2 things, no server in between, is this possible? Or can this file only be uploaded through another server?
If above things are not possible, how can I server check if the user really signed in? I am using Cloud Functions, but I did not came across a trigger for a user signing in. Please no answers with onDisconnect/onConnect, I want it server side. A user may NOT login if he is already logged in. Thanks :)
Implementing custom authentication requires that you have a secure place to mint the custom token that identifies each of your users. You cannot do this securely with only client-side code, because that would mean everyone could claim to be whoever they want.
While you can use Cloud Functions for Firebase to implement a secure back-end without spinning up your own server, I highly recommend against doing that just for the purpose of preventing a user to sign in from multiple locations.
It's important when talking about security to split these two steps:
Authentication - a user proving to be who they are
Authorization - the authenticated user being able to use your app
There very seldom is a reason to keep a user from proving who they are. Your concern seems to fall onto keeping them from using the app from multiple locations. To do that, it's probably easier to track for each user where they are using the app from already using Firebase Database's presence system.
Also see:
How to handle multiple connections of the same user on Firebase?
Android - How to detect same user from multiple devices?
How to prevent same user logging in from different devices ? My app is paid , so I dont want credentials to be shared

Security Concerns with Firebase Simple Login

I've been using Firebase as a way to synchronize data between a Rails application and a mobile web-kit based application. I've recently been attempting to use the email/password authentication method in lieu of custom auth tokens.
Everything works as expected, but my concern is with user creation and authentication.
Currently, I'm able to create a user, both on Rails (using a self-modified version of the firebase-ruby gem) and through the mobile app, using the firebase node module.
So from the stance of a malicious user, is it correct to assume that I can create a Simple Login user with the JS library (for anyone's firebase instance), and then authenticate with that user, and attempt to read any data that they have stored?
Of course one shouldn't leave their entire Firebase data structure unprotected. So this only works in a situation where one has only set up the default security rules.
Either way, is there any way to prevent anyone from creating users, except for myself (or some other authorized person) without resorting back to custom authentication? I understand the difference between authentication (the server knows who you are) and authorization (the server is letting you in).
Any feedback is appreciated.
In my conversation with Frank, it appears that there is no way to prevent malicious users from creating any number of accounts on a Firebase instance through email/password Simple Login. This doesn't allow them authorization to any data per se, but could be annoying for the SysAdmin/DevOp who was maintaining the Firebase instance.

Resources