Is there any way to see the specific collection / rule that is failing in Firestore? I've looked in firestore-debug.log (running on localhost) as well as in the Firebase UI. Firestore logs the error to the console, but does not include the information I need to debug the permissions:
Firebase intentionally does not disclose information about what rule is failing, as it would give malicious users information you don't want them to have.
The best information is typically available in the emulator in the Firebase console, which tells you what specific rule has failed.
Error messages delivered to the client SDK will never show the root cause of the rejection, as that would reveal something about the security measure to a potential attacker.
If you want to test and debug your security rules locally before you deploy, you can use the Firebase emulator suite to get detailed information about how your rules are working with client code that would make queries against them.
https://firebase.google.com/docs/firestore/security/test-rules-emulator
https://firebase.google.com/docs/rules/emulator-setup
Related
I am using firebase realtime database. Sometimes denies appear on the monitor rules page. I can't find which child has access denied. There doesn't seem to be a problem with the code. The security rules look fine too.
today I ran this code "firebase database:profile" and "firebase database:profile -o, --output filename" in terminal and created a profile today. All values in the Permission Denied column in the profile output are zero. but 67 denies appear on the monitor rules page from the browser. How do I find which child is access denied ? (for example: /user/info or /tflist/name. like this, I can't find exactly where there is an access problem.)
note: I tried to do it with Cloud Monitoring, but I couldn't find it too complicated. just the number of access blocks I can find. it does not show which child access is blocked there either.
Several questions have asked to run the firebase-admin package in the browser, such as
Can I break the rules and use firebase-admin on the client side? Or will trying to workaround errors be for nothing?
How to properly use Firebase Admin SDK using Node.js for a web-app?
Error importing firebase-admin
https://groups.google.com/g/firebase-talk/c/Jfq054TLEFQ?pli=1
However, both the questions and the answers given do not properly distinguish between the "browser vs. server/backend" distinction and the "end-user vs. privileged" distinction. A common theme seems to be warning against opening up firebase-admin for end-users, which is obviously a security risk, but they do not explain why a privileged user cannot access privileged Firebase functionality from code running in the browser, only from a backend / server.
So, assuming that a user has sufficient privileges (say, firebase project owner) and is willing to perform whatever authentication needed to transfer these privileges to code running in the browser -- what reasons are there for not doing this? Will it not work? Are there security risks? Is it simply discouraged because a significant fraction of developers will make mistakes WRT the exact requirements for making this work securely?
I think you have a misunderstanding about what a "privileged user" is, as you say.
firebase-admin is initialized with a service account. This is not the same as an Firebase Auth user account. Service accounts are entities belonging to a cloud project that are granted privileged access to some resources in that project. This is how fireabse-admin operates - you init with a service account and gain that privileged access. firebase-admin does not init with a user account.
You never want to expose a service account credentials to a web browser. That's a huge security risk. Since firebase-admin requires a service account, you will never want to use firebase-admin in the browser where it will be seen as public information.
The whole point of the documentation on the matter is to get you to write code to send Firebase Auth user tokens to your backend, where you can safely validate them and decide if that end user should be able to perform privileged operations using firebase-admin. There is really no safe workaround to this scheme - this is the pattern you should follow.
I have an app in production environment with remote logging of the client side errors. I get now and then this Firebase (firestore) security rules error:
FirebaseError: Missing or insufficient permissions.
When I check on the rules console, I can see that those errors are actually reported, but I have now way to see which rule specifically has provoked the error. I have no way to trace back which part of my client side code is triggering this error.
Any suggestions to find it? Any log from the Google console where I can dive?
In production no details are logged anywhere about what specific part of your security rules failed.
The two most common approaches to finding this are based on "replaying" the scenarios in your app:
In the rules playground in the Firebase console.
In the emulator suite, and its debug function.
In both cases I find it easiest to use a divide and conquer approach, enabling/disabling large chunks of my rules at a time to zoom in on what check might be rejecting the operation.
I developed a flutter app,
I use Firebase as my DB, which means that any user can write and read from my DB,
I'm getting the following email every couple of hours.
[Firebase] Your Cloud Firestore database has insecure rules
We've detected the following issue(s) with your security rules:
any user can read your entire database
any user can write to your entire database
Which is exactly what I want, since I want my app to be available to unregistered users.
Did I missed something? is my app is actually insecure?
The access to the DB is done through the app with filters only user specific data.
Is there a way to make my more secure, and keeping it available for unregistered users?
I also not sure why allowing only registered user will make it insecure, since any one can register to the app with a click of a button.
Please shed some light on this issue.
You will definitely need to learn how to use security rules. A full discussion is beyond the scope of a single answer, but you should know that security rules allow you to specify who (signed in through Firebase Auth) can read and write which documents and collections. Not using security rules at all is a massive security hole.
The video in the following documentation explain it in a very simple way
https://firebase.google.com/docs/firestore/security/get-started#writing_rules
The bottom line is that you must auth your users, and then use security rules for filtering the data, inorder for your data to be secured.
Using insecure rule should be done only for testing s
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.