How do I prevent other users from accessing my Realtime Database via my Firebase URL? What must I do to secure it to only my domain?
First of all, understand that you cannot secure any URL on the internet according to the origin domain--malicious users can simply lie. Securing the origin domains is only useful in preventing cross-site spoofing attacks (where a malicious source pretends to be your site and dupes your users into logging in on their behalf).
The good news is that users are already prevented from authenticating from unauthorized domains from the start. You can set your authorized domains in Forge:
type your Firebase url into a browser (e.g. https://INSTANCE.firebaseio.com/)
log in
click on the Auth tab
add your domain to the list of Authorized Requests Origins
select a "provider" you want to use and configure accordingly
Now to secure your data, you will go to the security tab and add security rules. A good starting point is as follows:
{
"rules": {
// only authenticated users can read or write to my Firebase
".read": "auth !== null",
".write": "auth !== null"
}
}
Security rules are a big topic. You will want to get up to speed by reading the overview and watching this video
Setup security Rules,
source to learn : https://firebase.google.com/docs/rules
Use Emulators (It will make keys not easy to visible by beginner programmers)
, source : https://firebase.google.com/docs/rules/emulator-setup
Cloud Functions (It will hide the names of Collections and Docs)
, https://firebase.google.com/docs/functions
Limit the API keys to specific website/s(It will make peoples unable to access your website/app from outside)
if someone knows more methods, please tell, no one can be perfect.
Related
hi i'm working with angular and firebase, in a web app, if i open the browser tools on console, i can see the connection keys to my firebase it's very bad.
the rules in firebase is the solution at this problem. but all answers i found are based on auth of users and on my web app is not necesary auth. how i can set rules so that only my web app can read and write without users auth. because if i create another projec and i use the same keys i can map the database and anyone can update the data thanks
p.d. my rules actually are read=true and write=true, this allows anyone to read and write.
{
"rules": {
".read": "true != null",
".write": "true != null"
}
}
P.d. my web app is hosted in Firebase Hosting thanks again
This is not possible with security rules. If you don't restrict usage with Firebase Authentication, that means anyone with an internet connection can read and write your database.
How do I prevent other users from accessing my Realtime Database via my Firebase URL? What must I do to secure it to only my domain?
First of all, understand that you cannot secure any URL on the internet according to the origin domain--malicious users can simply lie. Securing the origin domains is only useful in preventing cross-site spoofing attacks (where a malicious source pretends to be your site and dupes your users into logging in on their behalf).
The good news is that users are already prevented from authenticating from unauthorized domains from the start. You can set your authorized domains in Forge:
type your Firebase url into a browser (e.g. https://INSTANCE.firebaseio.com/)
log in
click on the Auth tab
add your domain to the list of Authorized Requests Origins
select a "provider" you want to use and configure accordingly
Now to secure your data, you will go to the security tab and add security rules. A good starting point is as follows:
{
"rules": {
// only authenticated users can read or write to my Firebase
".read": "auth !== null",
".write": "auth !== null"
}
}
Security rules are a big topic. You will want to get up to speed by reading the overview and watching this video
Setup security Rules,
source to learn : https://firebase.google.com/docs/rules
Use Emulators (It will make keys not easy to visible by beginner programmers)
, source : https://firebase.google.com/docs/rules/emulator-setup
Cloud Functions (It will hide the names of Collections and Docs)
, https://firebase.google.com/docs/functions
Limit the API keys to specific website/s(It will make peoples unable to access your website/app from outside)
if someone knows more methods, please tell, no one can be perfect.
I am curious if an user is able to write any data to the key they have writing permissions to. Ofcourse, normally this is done by authentication by the app they are using. But how well is it protected? If I am connected to my wifi I could use tamper data to change the network activities being send.
As stated here: Does firebase encrypt data with a unique key per account? It says that the data is encrypted before writing to the database. This however does not include changing the value's of the keys when the keys are not "arrived" at Firebase.
Is it possible to change the value's from monitoring the network activities, like tamper data?
Also, let's say these are some rules:
{
"rules": {
"users": {
"$uid": {
".read": "$uid === auth.uid",
".write": "$uid === auth.uid"
}
}
}
}
Is there any way a user could authenticate himself in any other way than using my app? How easy can a authenticated user change value's directly in the database, if he got write rules?
Thank you
In your provided rules, a user would be able to write arbitrary data to the node corresponding to their own uid, which can only be obtained via signing in with a form of Firebase Authentication (including minting a custom token server-side using the Firebase Admin SDKs).
100% of Firebase Realtime Database traffic is sent over TLS-encrypted connections. There is no way to man-in-the-middle this traffic and change it in flight.
You can trust Firebase Database Security Rules to do their job, but it is up to you to write robust rules that adequately protect data for your given application use cases. I'd recommend making use of .validate rules for structure and fine-grained .write rules everywhere. Another important tip to remember is that authorization is hierarchical. Once a .write rule is matched by a client all children of that node can be written by that client.
I'm new to Firebase and I'm attempting to set-up a simple authentication system using e-mail/password. The initial concept is simple: you register. Then, after logging in, you can access the rest of the mobile app.
In the past, I could set this up with PHP in just a few minutes. But with Firebase, this has become a battle that I can't seem to win.
Using the light documentation found on Firebase's site, I was finally able to successfully register and authenticate a user. Great.
Unfortunately, people can still access the rest of the app whether they are logged in or not. How do I keep the app protected from non-authenticated users?
Also, how do I associated data submitted on a page with an authenticated user?
I've looked at Firebase's documentation. It lacks practical examples for authentication. It keeps referring me to the Firefeed app as a sample. I've looked at Firefeed's code and the authentication system seems 1) excessively complicated for a login system and 2) too intricately tied in to news feeds to be a practical example to learn from.
On the other hand, perhaps I'm just missing something obvious and fundamental. If someone could point me in the right direction, that would be great. Thanks! :-)
(By the way, I tried e-mailing this question to firebase-talk#googlegroups.com, as suggested on Firebase's site... but the group does not appear to exist, according to the bounce-back message from Google.)
Stepping back for a moment, it's worth noting that Firebase Simple Login is an abstraction built on top of Firebase Custom Login for convenience. You can still use your existing authentication with Firebase using Custom Login, if you like.
Firebase Simple Login eliminates the need for you to run a server just for authentication. However, there is no 1-to-1 parallel to the PHP example where the server would govern request access based upon a detected session on the server because all of your logic, templates, etc. lives in client-side code.
In most cases, your client-side logic, templates, assets, etc. will be static and public. What you're really looking to secure is user and application data, and this is where Firebase Authentication (whether using Simple Login or Custom Login) comes in. Firebase Authentication is essentially token generation - taking confirmed, identifiable user data and passing it securely to Firebase so that it cannot be spoofed.
Read / write access to different paths in your Firebase data tree is governed by Firebase Security Rules, which allow you to write JavaScript-like expressions to control which clients can access which data.
Here's an example:
Suppose you have a user list, where each user is keyed by user id,
such as /users/<user-id>/<data>, and you want to ensure that only
the logged in user can read / write their own data. With Simple Login,
this is really easy!
Looking at the After
Authenticating
section of Email / Password authentication docs, we see that the
auth variable in our security rules will contain a number of fields
after authenticating, including id, the user's unique user id. Now
we can write our security rules:
{
"rules": {
".read": false,
".write": false,
"users": {
"$userid": {
".read": "auth != null && auth.uid == $userid",
".write": "auth != null && auth.uid == $userid"
}
}
}
}
What's going on here? Firebase Authentication (using Simple Login)
securely generated a token containing your verified user data upon
login, and that token data becomes available in your security rules
via the auth variable for the connection. Now, in order for a client
connection to read or write to /users/xyz, the user must be
authenticated and authenticated as user xyz.
Most of the above is covered in the Security Quickstart but it is admittedly a little hard to wrap your head around.
Back to your initial question, if you want to redirect away from certain paths when a user is not authenticated, you can do the following:
var ref = new Firebase(...);
var auth = new FirebaseSimpleLogin(ref, function(error, user) {
if (!user) {
// we're logged out, so redirect to somewhere else
} else {
// we're logged in! proceed as normal
}
});
Hope that helps!
Please note:
Login is now a core feature of Firebase. Simple Login has been
deprecated and documentation for this client is now available on
Github.
See this page for more info:
https://www.firebase.com/docs/web/guide/user-auth.html
How do I prevent other users from accessing my Realtime Database via my Firebase URL? What must I do to secure it to only my domain?
First of all, understand that you cannot secure any URL on the internet according to the origin domain--malicious users can simply lie. Securing the origin domains is only useful in preventing cross-site spoofing attacks (where a malicious source pretends to be your site and dupes your users into logging in on their behalf).
The good news is that users are already prevented from authenticating from unauthorized domains from the start. You can set your authorized domains in Forge:
type your Firebase url into a browser (e.g. https://INSTANCE.firebaseio.com/)
log in
click on the Auth tab
add your domain to the list of Authorized Requests Origins
select a "provider" you want to use and configure accordingly
Now to secure your data, you will go to the security tab and add security rules. A good starting point is as follows:
{
"rules": {
// only authenticated users can read or write to my Firebase
".read": "auth !== null",
".write": "auth !== null"
}
}
Security rules are a big topic. You will want to get up to speed by reading the overview and watching this video
Setup security Rules,
source to learn : https://firebase.google.com/docs/rules
Use Emulators (It will make keys not easy to visible by beginner programmers)
, source : https://firebase.google.com/docs/rules/emulator-setup
Cloud Functions (It will hide the names of Collections and Docs)
, https://firebase.google.com/docs/functions
Limit the API keys to specific website/s(It will make peoples unable to access your website/app from outside)
if someone knows more methods, please tell, no one can be perfect.