Using firebase rules as:
{
"rules": {
".read": true,
".write": true
}
}
means that everyone inside my application can read/write the firebase resource or means everyone including any request not necessary comming from my application can read/write?
With these rules, I can:
Get your entire database with a single URL, which you actually ship in application source code. I don't even need to use your app for this, I can just do https://<yourdatabaseURL>/.json and get it all.
Wipe your entire database with a single line of code, from a tool as simple as the JavaScript console of my browser.
So yeah, it's pretty much as insecure as all the reports make it out to be.
Since you have to include the URL in your app in order to be able to access database, leaving the rules like this is just asking for problems.
You should secure your database by using Firebase App Check to make it harder to access the database outside of your application, and then implement proper security rules to have fine-grained access control.
Ideally you should:
Start with the exact opposite rules, that deny all access, then
Implement the first small use-case of your application in code.
Watch it get rejected by the security rules.
Change your rules to allow only that one use-case, and nothing else.
Go on to the next use-case.
This is known as the principle of least privilege and is key to protecting the data.
I recommend also checking out these other questions on the same (really broad) topic:
Is it safe to expose Firebase apiKey to the public?
Does Firebase App Check discard the need for implementing Security Rules?
Firebase Permission Denied
Firebase email saying my realtime database has insecure rules
Related
I am using Firebase Realtime Database for chat functionality in my app. Now we are ready to launch our app so we should fix this issue. xxxx-xxxx-4458' has insecure rules. In official documentation and other places i have found only solution where we need to use firebase auth for validation, But our main database and login process works on our own server and we are using firebase realtime chat as only for chat purpose, so we are not using any firebase authentications so we are still not able to fix issues.
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
So Is there is any other way to secure our database without using firebase authentications.
Our Firebase Implementations.
We are using our own server for all the user login,sessions and user data. User login and validate is perform by our own server. That's why we don't use firebase for any other app functions than Real time chat.
As we are not using firebase auth for user validation. It's not possible by us to secure realtime database. User login,registration,sessions,validations all perform by our own server and after validations from our own server then user can start sending message with realtime database.
Our current rules
{
"rules": {
".read": true,
".write": true
}
}
Question:
Are we already secured from outsider attack(non-app user). If no then how we can make our database secure in our scenario?.
Update: That's How my database arranged.
Now on successful login on our server, I am generating JWT and using it as
mAuth.signInWithCustomToken(mCustomToken)
.addOnCompleteListener(this, new OnCompleteListener<AuthResult>() {
#Override
public void onComplete(#NonNull Task<AuthResult> task) {
if (task.isSuccessful()) {
// Sign in success
} else {
// If sign in fails
Toast.makeText(CustomAuthActivity.this, "Authentication failed.",
}
}
});
I don't understand where/how to validate that token on firebase Auth. Please put insight on it.
With your current rules anyone in the world can wipe your database with a single API call. They can also read the entire database with a single API call. Neither of those are likely use-cases that your app requires, so I'd say your app is currently not secure.
If you want to properly secure access based on the user identity, you can inform Firebase Authentication of the profile of the user in your own identity system by implementing custom authentication. Once you have that implemented, the auth variable in your security rule will contain the information from your own user system, and you can then use that to secure access to the data.
Even if you know nothing about the user though, you can already secure your app better than what you currently have, by writing rules that fit your use-cases.
For example, since you have a chat app, you likely have a list of chat messages, and users append new messages to this list. Instead of saying that everyone can do whatever they want to the root of your database, you can only allow them to post chat messages with something like:
{
"rules": {
"chat": {
".read": true,
"$message_id": {
".write": true
}
}
}
}
So now, users can only read the /chat node, and they can only write specific nodes under it. Just this simple change already rules out a whole lot of abuse scenarios.
One step better, would be to validate that the chat messages are of the structure that you expect. For example, if the message have a user name, timestamp, and a text message, that could be:
{
"rules": {
"chat": {
".read": true,
"$message_id": {
".write": true,
".validate": "newData.hasChildren('name', 'timestamp', 'text')"
}
}
}
}
At this point you should note that these rules reflect some of your application code, which is normal: your security rules should only allow what your application code needs, and nothing more. This is known as the principle of least privilege, and is a common security practice.
Finally, you should probably also consider using Firebase App Check which can also prevent a lot of abuse by folks who are not using your application to access the database. Note that this is not a guarantee though, so you'll want to combine App Check for broad protection with security rules for fine-grained control.
Some more resources:
Firebase email saying my realtime database has insecure rules
Firebase says that my rules are insecure, why?
Issue with my Firebase realtime data base security rules
Firebase Rules Write Permissions
I am new to Firebase and I want to understand it
How do I make Database safe?
When i using real-time database, if i make rules like this:
{
"rules": {
".read": true,
".write": true
}
}
Is this safe?
If it is not safe for my app, how do I make it safe?
What does it mean to add auth (users who have registered) reading and writing in the rules, is it a good way to protect databases, and how do I do this?
If the rules are true, what are the risks that implementation may face and when? What is the alternative? – TaHa M. Younis 22 mins ago
The security rules of your app depend almost solely on the business logic of the app. So just like you will have to figure out the code to match your use-cases, you also have to figure out the security rules (and data model) to match your use-cases. There is no way for us to do that for you in a simple Q&A fashion here.
I highly recommend getting started with the Firebase documentation on security rules, which includes an explanation of concepts, how security rules work, and some great examples of common use-cases such as content-owner only access, role-based and attribute-based access control and others.
I am developing an Ionic application. My app is almost done, I just have to fix some bugs, but I have security concerns. I do not have a server side application, everything is inside of the ionic app itself.
Since I have database calls and writes and edits how secure is my application? Is it possible that someone could reverse engineer the apk, change some firebase code and completely ruin my database and application? How does this work and how can i secure my application?
Also, which rules should I apply in firebase? Currently I have the default testing rules:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true;
}
}
}
I am new to firebase and I dont quite understand the rules. I have two collections users and matches, and I want a specific user to only write and read from the user document which is his (has his id) and read and write to every document inside matches, that contains his id inside.
Since I have database calls and writes and edits how secure is my application?
It's not secure at all.
Is it possible that someone could reverse engineer the apk, change some firebase code and completely ruin my database and application?
With the security rules you show here, that is very possible. Your database allows full read and write access to anyone with an internet connection.
There's not enough information in your question to say exactly what you need to do. I strongly suggest first reviewing the documentation for security rules, and learn how to apply rules for your specific case. If you are having problems with specific code and rules, please post a question that shows the combination of client code and security rules that aren't working the way you expect.
Since I want to fetch data without authentication for my app, my security rules look like this:
{
"rules": {
".read": true,
".write": false
}
}
But Firebase said if someone has this URL he can fetch my data. How could I save my data. My app doesn't require authentication. How could I resist other, or what configuration I can set so only my app can fetch it.
In simple words,
No one should allow to fetch my app data(firestore) without my app. Where my app doesn't require authentication.
What you're asking for isn't possible. These things are all exactly the same:
Accessing data via client SDK without authentication
Accessing data with the REST API without an authentication token
Accessing data in any way without using the app itself
If you want to restrict data to your app only, you will need some form of authentication provided by Firebase Authentication.
You have to use firebase Anonymous Authentication, This authentication doesn't require user input like email, password, SSO, etc. You can just set the code inside a button to Get Started, So firebase will automatically create a userID for each user.
I'm trying understand which is the best way to store sensitive data in Android. In my app i want to insert a classic in-app-purchase model with some coins. My problem is that i'm not sure how to implement this correctly.
The initial idea was to simply use my firebase database, store the number of coins for every user and fetch the data every time the app is launched. This way I can easily detect some inappropriate usage but my users are forced to use the internet to play.
Looking at the documentations, I found this. Can this be a solution? Can I save in the internal storage the number of coins, maybe with some type of encryption, to avoid root user to modify the file? Then when the internet is on I can double-check the local stored variable with the the one in the database.
Thanks
Not an "easy" task.
Technically, you can create a SecretKey and encrypt data, so no normal user will be able to reproduce. If your concern are root users, You are kind of out of luck, as he can hook into your app while it is reading/writing that value.
But to store it online is not a solution in itself. You have to answer questions like: "Do you trust any server input"?
"How to make sure just paid coins are added"?
Have you had a look at Google Play billing?
it provides safe way's to determine if somebody paid or not.
This will require to be online.
If you have a sensitive data to save you can use sqlcipher database .. the good with it that it encrypt the database file itself so even the root user be able to get the database file he will not be able to decrypt it if you use a secured encryption algorithm.
you can find more about sqlcipher here
https://www.zetetic.net/sqlcipher/sqlcipher-for-android/
Since I assume you will grant your app a reading permission of your sensitive data and all writing processes should be reserved server-side, I would not recommend storing the data in a file on a phone, though every encryption can potentially be passed.
Maybe you already have heard about SharedPreferences, which is a good solution for let's say Preferences the user selects and that only shall affect his particular installation of your app. The difference is, that values are not stored in an external file, so not that easy accessible, BUT your app needs to write them, due only the app can access them directly (also your server can't). I am not aware of how your sensitive data is used at all but I would also not use SharedPreferences since it's injective-prone.
Official docs about SharedPreferences.
If security of your data (speaking of Confidentiality, Integrity, Authentication) is your No. 1 priority, simply don't store your sensitive data on the users device. Focus more on creating an API that ensures secure and performant passing of the relevant bits of your sensitive data. Hope this helps to give you a view of which way to go and which to walk around.