Hope you guys are all doing well. I just have a quick question regarding Firebase and how if Firebase has any sort of ways to detect malicious users?
The scenario I am imagining is that some user downloaded my app and for whatever reason wrote some script or something that just continuously reads and writes to my Firebase firestore and/or storage
I am wondering if Firebase has any built in functionality that detects any unusual amounts of read/writes from a single user or what are some ways I can do so to prevent a user from, say, read and/or write more than 100 times within 1 min?
Thanks
Firebase doesn't have any per-user accounting. If you want to record what each user is doing and enforce limits, you'll have to implement that yourself. Security rules also will be of little help to you enforcing overall read limits. You will have to:
Force all users to access the database through a backend you control
Send the identity of the user along with the request
Record somewhere how much that user has read and written
Refuse to perform more queries if that limit is exceeded, for whatever threshold or duration you define.
In short, it's a lot of work you have to do yourself.
I assign role to user only to read and write after authenticated in firebase database.
I feel like someone can still login to my database to write and read excessive amount of time to owe me money on Google.
Only thing I can do seems monitor my database and send alert to my phone and stop server to prevent this.
Is this only way I can do to situation like this, or Is there any good option to solve my concern ?
You can't stop authenticated users who have permission to query from making queries. What you can do is set up budget alerts in the Google Cloud console, which should apply to all Firebase products as well.
How can I make sure my firebase realtime database data is not accessible (read or download) via REST or any other way ?
I am very concerned about this as it seem to be a common way (not to secure properly your database) to steal data from apps.
My nodes all have the same security for reading : authentification required.
Thank you !
It sounds like you've left the default security rules, which simply require a user to be signed in to be able to read/write all data. While this blocking of unauthenticated users is a good first step, there is probably more you can do.
The Firebase documentation explain how you can use Firebase's server-side security rules to precisely control what data each user can access. I highly recommend also watching the video in there, for a good introduction of what mindset to have while thinking of securing your data in this way.
Ok so I found the exact answer I was looking for : if you want to download data that needs authentification with REST, you need a token.
So to sum up : No, 'simple' users can not download nodes that are protected by security rules, they also need a token that only the admin can generate.
Please feel free to correct me if all the above is wrong
Let's say I'm developing app like Instagram: for iOS, Android and Web. I decided to use Google Firebase as it really seems to simplify the work.
The features user needs in the app are:
Authorization/Registration
Uploading photos
Searching for other people, following them and see their photos
I come from traditional "own-backend" development where I do need to setup a server, create database and finally write the API to let the frontend retrieve the data from the server. That's the reason why it's unclear to me how it all works in Firebase.
So the question is how can I create such app:
Should I create my own API with cloud functions? Or it's ok to work with the database directly from the client-side?
If I work with the database directly why do I need cloud functions? Should I use them?
Sorry for such silly questions, but it is really hard to get from scratch.
The main difference between Firebase and the traditional setup you describe is that with Firebase, as far as the app developer is concerned, the client has direct access to the database, without the need for an intermediate custom API layer. Firebase provides SDKs in various languages that you would typically use to fetch the data you need / commit data updates.
You also have admin SDKs that you can use server-side, but these are meant for you to run some custom business logic - such as analytics, caching in an external service, for exemple - not for you to implement a data fetching API layer.
This has 2 important consequences:
You must define security rules to control who is allowed to read/write at what paths in your database. These security rules are defined at the project level, and rely on the authenticated user (using Firebase Authentication). Typically, if you store the user profile at the path users/$userId, you would define a rule saying that this node can be written to only if the authenticated user has an id of $userId.
You must structure your data in a way that makes it easily readable - without the need for complex database operations such as JOINs that are not supported by Firebase (you do have some limited querying options tough).
These 2 points allow you to skip the 2 main roles of traditional APIs: validating access and fetching/formatting the data.
Cloud functions allow you to react to data changes. Let's say everytime a new user is created, you want to send him a Welcome email: you could define a cloud function sending this email everytime a new node is appended to the users path. They allow you to run the code you would typically run server-side when writes happen, so they can have a very broad range of use-cases: side-effects (such as sending an email), caching data in an external service, caching data within Firebase for easier reads, analytics, etc..
You don't really need a server, you can access the database directly from the client, as long as your users are authenticated and you have defined reasonable security rules on Firebase.
In your use case you could, for example, use cloud functions to create a thumbnail when someone uploads a photo (Firebase Cloud Functions has ImageMagick included for that), or to denormalize your data so your application is faster, or to generate logs. So, basically you can use them whenever you need to do some server side processing when something changes on your database or storage. But I find cloud functions hard to develop and debug, and there are alternatives such as creating a Node application that subscribes to real time changes in your data and processes it. The downside is that you need to host it outside Firebase.
My answer is definitely NOT complete or professional, but here are the reasons why I choose Cloud Functions
Performance
You mentioned that you're writing an instagram-like mobile device app, then I assume that people can comment on others' pictures, as well as view those comments. How would you like to download comments from database and display them on users' devices? I mean, there could be hundreds, maybe thousands of comments on 1 post, you'll need to paginate your results. Why not let the server do all the hard work, free up users' devices and wait for the results? This doesn't seem like a lot better, but let's face it, if your app is incredibly successful, you'll have millions of users, millions of comments that you need to deal with, server will do those hard jobs way better than a mobile phone.
Security
If your project is small, then it's true that you won't worry about performance, but what about security? If you do everything on client side, you're basically allowing every device to connect to your database, meaning that every device can read from/write into your database. Once a malicious user have found out your database url, all he has to do is to
firebase.database().ref(...).remove();
With 1 line of code, you'll lose all your data. Okay, if you say, then I'll just come up with some good security rules like the one below:
This means that for each post, only the owner of that post can make any changes to it or read from it, other people are forbidden to do anything. It's good, but not realistic. People are supposed to be able to comment on the post, that's modifying the post, this rule will not apply to the situation. But again, if you let everybody read/write, it's not safe again. Then, why not just make .read and .write false, like this:
It's 100% safe, because nobody can do anything about anything in your database. Then, you write an API to do all the operations to your database. API limits the operations that can be done to your database. And you have experience in writing APIs, I'm sure you can do something to make your API strong in terms of security, for example, if a user wants to delete a post that he created, in your deletePost API, you're supposed to authenticate the user first. This way, 'nobody' can cause any damage to your database.
It is unclear whether or not to set security rules for database.
Is it enough to just let in just authenticated users? Do I need more complicated things? I have android app, and do all validations and updates inside app.
The video from IO says that there is possibility that someone can get all your data if he knew your app ID. So if user is authenticated and have app ID and somehow build web app he can get data too? I mean if using simple rules.
I`m asking for risks when building just android app and using simple rules (auth is on).
Is it ok for you if any user could edit/create/delete any data in your Firebase database? If this is not ok, you need security rules (you probably need them)
Firebase's security rules are really powerful and easy to use, I suggest you take a look at the documentation.
You need user id or role specific rules, otherwise somebody for example can easily wipe out your all data, or easily manipulate anything.