I've been wrestling with Firebase security for a little while now and am not having much luck with a scenario that I don't think is very unique (but it is also not covered in the documentation).
Imagine I have a tree, test_tree, which is at the root of my Firebase database. From there, I have three children under test_tree named requiredString1, requiredString2, and optionalString1.
I would like for an authenticated user of the Firebase to be able to write to test_tree, and require that both of the requiredString children are included, while allowing optionalString1 to be optional. There is one additional caveat which is throwing me for a loop -- although optionalString1 is optional, it should not be allowed to be deleted.
So, with those requirements in mind, I've come up with the following security rules:
"rules" {
"test_tree": {
//Define overall write rules
".write": "
auth !== null &&
newData.exists() //this is done to ensure that a deletion of this tree cannot occur
",
".validate": "
newData.hasChildren(['requiredString1', 'requiredString2'])
",
//Define rules for each child
"requiredString1":{
".validate": "
newData.isString()
"
},
"requiredString2":{
".validate": "
newData.isString()
"
},
"optionalString1":{
".validate": "
newData.isString()
"
},
//And finally, ensure no other miscellaneous children can be written
"$other": {
".validate": false
}
},
//Also, ensure lockdown on all other root trees
"$other": {
".read": false,
".write": false,
".validate": false
}
}
I've started to put together a test suite to test my rules as I go along, but the optional-yet-not-delete rule is causing problems.
With the above rules, I fail on two tests:
A write to test_tree with following payload is allowed (this needs to fail).
{
requiredString1: "string1",
requiredString2: "string2",
optionalString1: null
}
A write to test_tree/optionalString1 with payload of null is allowed (this needs to fail).
I've tried to get tricky with my validation rules, such as:
"rules": {
...
".validate": "
//Ensure that required values are present
newData.hasChildren(['requiredString1', 'requiredString2']) &&
(
//IF optionalString is included, ensure that it's not null
(
newData.hasChild('optionalString1') &&
newData.hasChild('optionalString1').val() !== null
)
||
//But also allow it to be non-present
!newData.hasChild('optionalString1')
)
"
...
}
But, unfortunately, this results in the same errors as before.
I've tried some other rule structures as well including actually moving the entire rule set into each child location (and removing the .write and .validate rules at the parent test_tree location), but then writes to the parent location (that previously worked) would then fail.
Some help here? Again, I would think that allowing data to be optional, yet still prevent deletion, would be a common need.
EDIT 1:
I've spent some time thinking about my question, and I think the requirement is a little bit of a misnomer. Basically, what I was asking for was that the data be optional if and only if it's not present in the Firebase database. If it is present in the Firebase, it essentially becomes required.
However, once I realized that was the true requirement, it made describing the use case easier. Hopefully, it'll be clear in a moment, but basically the use case is protecting the developer that is interfacing with Firebase from themselves.
Imagine there is a tree of several descriptors for an item, and the tree looks like the following:
items: {
item_ID1: {
name: "Item Name",
descriptorA: "A descriptor",
descriptorB: "Another descriptor"
}
}
Basically, I was thinking that descriptorA and descriptorB would be optional, and the name would be required. In the event that name needed to be changed whereas descriptorA and descriptorB would remain the same, I wanted to protect the developer that is writing the interface to this data from being able to accidentally blast descriptorA and descriptorB by using a .set({item_ID1: {name: "New Name"}}).
I think this actually can be accomplished with the following rules:
"rules": {
"items": {
".write": "
auth !== null &&
newData.exists()
",
".validate": "
newData.hasChild('name') &&
(
!data.hasChild('descriptorA') ||
(data.hasChild('descriptorA') && newData.hasChild('descriptorA'))
) &&
(
!data.hasChild('descriptorB') ||
(data.hasChild('descriptorB') && newData.hasChild('descriptorB'))
)
",
"name": {
".validate": "newData.isString()"
",
"descriptorA": {
".validate": "newData.isString()"
",
"descriptorB": {
".validate": "newData.isString()"
",
"$others": {
".validate": false
}
}
}
The first problem is (as you said) that .validate rules are not executed if there is no new data. So you'll need to detect the condition in a .write rule.
The second problem (as you also said) is that "rules cascade", so if you give allow an operation on a higher level node, you cannot take it away on a lower level. For that reason, you'll need to detect the condition on a higher level in the JSON structure.
So the solution is to use a .write rule, higher in the JSON tree.
"test_tree": {
".write": "newData.exists() && (newData.hasChild('optionalString') || !data.hasChild('optionalString'))",
".validate": "newData.hasChildren(['requiredString'])",
"requiredString": {
".validate": "newData.isString()"
},
"optionalString":{
".validate": "newData.isString() || !data.exists()"
},
"$other": {
".validate": false
}
I've simplified your data structure a bit, to only include a single required and a single optional property.
This is all described in EDIT 1 above.
I've spent some time thinking about my question, and I think the requirement is a little bit of a misnomer. Basically, what I was asking for was that the data be optional if and only if it's not present in the Firebase database. If it is present in the Firebase, it essentially becomes required.
However, once I realized that was the true requirement, it made describing the use case easier. Hopefully, it'll be clear in a moment, but basically the use case is protecting the developer that is interfacing with Firebase from themselves.
Imagine there is a tree of several descriptors for an item, and the tree looks like the following:
items: {
item_ID1: {
name: "Item Name",
descriptorA: "A descriptor",
descriptorB: "Another descriptor"
}
}
Basically, I was thinking that descriptorA and descriptorB would be optional, and the name would be required. In the event that name needed to be changed whereas descriptorA and descriptorB would remain the same, I wanted to protect the developer that is writing the interface to this data from being able to accidentally blast descriptorA and descriptorB by using a .set({item_ID1: {name: "New Name"}}).
I think this actually can be accomplished with the following rules:
"rules": {
"items": {
".write": "
auth !== null &&
newData.exists()
",
".validate": "
newData.hasChild('name') &&
(
!data.hasChild('descriptorA') ||
(data.hasChild('descriptorA') && newData.hasChild('descriptorA'))
) &&
(
!data.hasChild('descriptorB') ||
(data.hasChild('descriptorB') && newData.hasChild('descriptorB'))
)
",
"name": {
".validate": "newData.isString()"
",
"descriptorA": {
".validate": "newData.isString()"
",
"descriptorB": {
".validate": "newData.isString()"
",
"$others": {
".validate": false
}
}
}
Related
EDIT: Figured it out. Multi-location updates work not like updates as far as they seem to overwrite pre-existing values.
I have a hard time figuring out security rules for multi location updates. Until now I had this code
return this.userProfileRef.child(firebase.auth().currentUser.uid).update(profileData);
to update a user profile in fb, where profileData is an object containing some fields.
when I try to do the same operation, but written in a way that I can add more write operations (multi-location update), I get a validation error.
var updateData = {};
updateData['users/' + firebase.auth().currentUser.uid] = profileData;
return firebase.database().ref().update(updateData);
my security rules are
{
"rules": {
".write": "true",
".read": "true",
"users": {
"$uid": {
".read": "$uid === auth.uid",
".write": "!data.exists() || ( data.exists() && auth.uid === $uid )",
"profileStatus": {
".validate": "!data.exists() || (newData.parent().hasChildren(['firstName', 'dateOfBirth', 'gender', 'lookingForGender', 'lookingForAgeMin', 'lookingForAgeMax', 'lookingForRadius']) && data.val() === 'incomplete' && newData.val() === 'awaitingVerification')"
}
}
}
}
Validation fails in profileStatus, when I do the multi-location update as written above, but passes when I do a 'normal' update.
Can someone help out and tell me what I'm missing here. Does fb handle multi-location updates differently when it comes to security rules?
Thanks.
Okay, to answer my own question. It seems that multi-loation update works more like a multi-lcoation set, so it overwrites existing values which caused my validation fail.
I'm still confused by this beviour… following the firebase blog here I thought, it would wor like an update.
In my example, i have a pre-existing key called dateOfBirth. This key gets deletd when I run the multi-update
Perhaps I'm tackling this problem too much from an SQL kind of perspective, but I'm having troubles understanding how to properly restrict which children should be allowed to populate a node.
Say that I want to keep a record of products with arbitrary names. Each product must contain a price, but nothing else is allowed.
My naive approach was to add a .validate rule to the products requiring newData to contain a price child, explicitly granting write access to the price node and then removing all access an $other node (somewhat like a default clause in a switch statement):
{
"rules": {
"$product": {
".read": true,
".write": true,
".validate": "newData.hasChildren(['price'])",
"price": {
".write": true,
".validate": "newData.isNumber()"
},
"$other": {
".read.": false,
".write": false,
}
}
}
}
This does not work. Adding a new product with {"price": 1234, "foo": "bar"} will still be accepted. If I however add a ".validate": false rule to $other, nothing is accepted instead (e.g. {"price": 1234} is not allowed). (I did that wrong, somehow.)
Is there some way to implement something similar to what I'm trying to do here? If not, what is the proper way of restricting a data structure in Firebase? Should I do it at all? What stops the user from filling my database with trash if I don't?
You're falling into a few common Firebase security pits here. The most common one is that permission cascades down: once you've granted read or write permission on a certain level in the tree, you cannot take that permission away at a lower level.
That means that these rules are ineffectual (since you've granted read/write one level higher already):
"$other": {
".read.": false,
".write": false,
}
To solve the problem you must realize that .validate rules are different: data is only considered valid when all validation rules are met. So you can reject the $other data with a validation rules:
{
"rules": {
"$product": {
".read": true,
".write": true,
".validate": "newData.hasChildren(['price'])",
"price": {
".validate": "newData.isNumber()"
},
"$other": {
".validate": false
}
}
}
}
I am building a simple Firebase application with AngularJS. This app authenticates users through Google. Each user has a list of books. Anyone can see books, even if they are not authenticated. Only the creator of a book can edit it. However, individual users need to be able to record that they've read a book even if someone else added it.
I have rules.json like so:
{
"rules": {
".read": false,
".write": false,
"book": {
"$uid": {
".write": "auth !== null && auth.uid === $uid",
}
".read": true,
}
}
}
And I am trying to write a book simply with:
$firebaseArray(new Firebase(URL + "/book")).$add({foo: "bar"})
I get a "permission denied" error when trying to do this although I do seem to be able to read books I create manually in Forge.
I also think that the best way to store readers would be to make it a property of the book (a set of $uid for logged-in readers). ".write" seems like it would block this, so how would I do that?
"$uid": {
".write": "auth !== null && auth.uid === $uid",
"readers": {
".write": "auth !== null"
}
},
It seems like a validation rule would be appropriate here as well ... something like newData.val() == auth.uid, but I'm not sure how to validate that readers is supposed to be an array (or specifically a set) of these values.
Let's start with a sample JSON snippet:
"book": {
"-JRHTHaIs-jNPLXOQivY": { //this is the generated unique id
"title": "Structuring Data",
"url": "https://www.firebase.com/docs/web/guide/structuring-data.html",
"creator": "twiter:4916627"
},
"-JRHTHaKuITFIhnj02kE": {
"title": "Securing Your Data",
"url": "https://www.firebase.com/docs/security/guide/securing-data.html",
"creator": "twiter:209103"
}
}
So this is a list with two links to articles. Each link was added by a different user, who is identified by creator. The value of creator is a uid, which is a value that Firebase Authentication provides and that is available in your security rules under auth.uid.
I'll split your rule into two parts here:
{
"rules": {
".read": false,
"book": {
".read": true,
}
}
}
As far as I see your .read rule is correct, since your ref is to the /book node.
$firebaseArray(new Firebase(URL + "/book"))
Note that the ref below would not work, since you don't have read-access to the top-level node.
$firebaseArray(new Firebase(URL))
Now for the .write rules. First off is that you'll need to grant users write-access on the book level already. Calling $add means that you're adding a node under that level, so write-access is required.
{
"rules": {
"book": {
".write": "auth != null"
}
}
}
I leave the .read rules out here for clarity.
This allows any authenticated user to write to the book node. This means that they can add new books (which you want) and change existing books (which you don't want).
Your last requirement is most tricky. Any user can add a book. But once someone added a book, only that person can modify it. In Firebase's Security Rules, you'd model that like:
{
"rules": {
"book": {
".write": "auth != null",
"$bookid": {
".write": "!data.exists() || auth.uid == data.child('creator').val()"
}
}
}
}
In this last rule, we allow writing of a specific book if either there is no current data in this location (i.e. it's a new book) or if the data was created by the current user.
In the above example $bookid is just a variable name. The important thing is that the rule under it is applied to every book. If needed we could use $bookid in our rules and it would hold -JRHTHaIs-jNPLXOQivY or -JRHTHaKuITFIhnj02kE respectively. But in this case, that is not needed.
First off the "permission denied" error. You are getting this error because you are trying to write directly in the "book" node instead of "book/$uid".
Example of what you do now:
"book": {
"-JRHTHaIs-jNPLXOQivY": { //this is the generated unique id
"foo": "bar"
},
"-JRHTHaKuITFIhnj02kE": {
"foo": "bar"
}
}
In your rules you have a global rule for write set to false so that will be the default and next to that you have made a rule for the specific node book/$uid. So when trying to write directly in "book" it will take the default rule that was set to false. Have a look at Securing your data for more information about firebase rules.
And for the last part of your question i suggest you take a look at Structuring data for more information about the best ways to structure your data inside firebase.
So taka a good look at what and how you want to save and write in firebase and make sure your rules are structured accordingly.
We are offering a service that people will embed on their web site and we are hoping to use Firebase as our backend. We would like to base our subscription rates on page views or something similar. Right now we are stumped trying to figure out how to prevent customers from caching our client js code and omitting any portions that attempt to increment a page views counter.
What we need to do somehow is create a security rule that atomically prevents someone from reading from one location unless they have incremented the counter at another location. Any ideas on how to do this?
For example, assuming the following schema:
{
"comments" : {
"-JYlV8KQGkUk18-nnyHk" : {
"content" : "This is the first comment."
},
"-JYlV8KWNlFZHLbOphFO" : {
"content" : "This is a reply to the first.",
"replyToCommentId" : "-JYlV8KQGkUk18-nnyHk"
},
"-JYlV8KbT63wL9Sb0QvT" : {
"content" : "This is a reply to the second.",
"replyToCommentId" : "-JYlV8KWNlFZHLbOphFO"
},
"-JYlV8KelTmBr7uRK08y" : {
"content" : "This is another reply to the first.",
"replyToCommentId" : "-JYlV8KQGkUk18-nnyHk"
}
},
oldPageViews: 32498,
pageViews: 32498
}
What would be a way of only allowing read access to the comments if the client first incremented the pageViews field? At first I was thinking about having two fields (something like pageViews and oldPageViews) and starting out by incrementing pageViews, reading the comments, then incrementing oldPageViews to match, and only allowing read on comments if pageViews === oldPageViews + 1. However, unless this could be done atomically, the data could get into a corrupt state if the client started the process but didn't finish it.
Here is a codepen trying to test this idea out.
I would suggest a variation of Kato's rate limiting answer : https://stackoverflow.com/a/24841859/75644
Data:
{
"comments": {
"-JYlV8KQGkUk18-nnyHk": {
"content": "This is the first comment."
},
"-JYlV8KWNlFZHLbOphFO": {
"content": "This is a reply to the first.",
"replyToCommentId": "-JYlV8KQGkUk18-nnyHk"
},
"-JYlV8KbT63wL9Sb0QvT": {
"content": "This is a reply to the second.",
"replyToCommentId": "-JYlV8KWNlFZHLbOphFO"
},
"-JYlV8KelTmBr7uRK08y": {
"content": "This is another reply to the first.",
"replyToCommentId": "-JYlV8KQGkUk18-nnyHk"
},
"timestamp" : 1413555509137
},
"pageViews" : {
"count" : 345030,
"lastTs" : 1413555509137
}
}
Security Rules:
{
"rules": {
"pageViews": {
".validate": "newData.hasChildren(['count','lastTs'])",
"count": {
".validate": "newData.exists() && newData.isNumber() && newData.val() > data.val()"
},
"lastTs": {
// timestamp can't be deleted or I could just recreate it to bypass our throttle
".write": "newData.exists()",
// the new value must be at least 500 milliseconds after the last (no more than one message every five seconds)
// the new value must be before now (it will be since `now` is when it reaches the server unless I try to cheat)
".validate": "newData.isNumber() && newData.val() === now && (!data.exists() || newData.val() > data.val()+500)"
}
},
"comments": {
// The comments can't be read unless the pageViews lastTs value is within 500 milliseconds of now
".read": "root.child('pageViews').child('lastTs').val() > now - 501",
".write": true
}
}
}
NOTE : I haven't tested this so you need to play around with it a bit to see if it works.
Also, based on your sample data, I didn't deal with uid's. You need to make sure you're managing who can read/write here.
Justin's adaptation to the throttling code seems like a great starting point. There are a few annoying loopholes left, like forcing the counter to be updated, getting quantifiable metrics/analytics out of your counter (which requires hooking into a stats tool by some means and will be necessary for accurate billing reports and customer inquiries), and also being able to accurately determine when a visit "ends."
Building from Justin's initial ideas, I think a lot of this overhead can be omitted by simplifying the amount the client is responsible for. Maybe something like:
Only force the user to update a timestamp counter
Employ a node.js script to watch for updates to the counter
Let the node.js script "store" the audit data, preferably by
sending it to analytics tools like keen.io, intercom.io, etc.
Starting from this base, I'd adapt the security rules and structure as follows:
{
"rules": {
"count": {
// updated only from node.js script
// assumes our node worker authenticates with a special uid we created
// http://jsfiddle.net/firebase/XDXu5/embedded/result/
".write": "auth.uid === 'ADMIN_WORKER'",
".validate": "newData.exists() && newData.isNumber() && newData.val() > data.val()"
},
"lastTs": {
// timestamp can't be deleted or I could just recreate it to bypass our throttle
".write": "newData.exists()",
// the new value must be equal to now (i.e. Firebase.ServerValue.TIMESTAMP)
".validate": "newData.isNumber() && newData.val() === now"
},
"comments": {
// The comments can't be read unless the pageViews lastTs value is within 30 seconds
".read": "root.child('pageViews').child('lastTs').val() > now - 30000",
"$comment": {
".write": "???"
}
}
}
}
Now I would write a simple node script to perform the count and administrative tasks:
var Firebase = require('firebase');
var ref = new Firebase(URL);
ref.child('lastTs').on('value', heartbeatReceived);
var lastCheck = null;
function heartbeatReceived(snap) {
if( isNewSession(snap.val()) ) {
incrementCounter();
}
updateStatsEngine(snap);
}
function incrementCounter() {
ref.child('count').transaction(function(currVal) {
return (currVal||0) + 1;
});
}
function isNewSession(timestamp) {
// the criteria here is pretty arbitrary and up to you, maybe
// something like < 30 minutes since last update or the same day?
var res = lastCheck === null || timestamp - lastCheck > 30 * 60 * 1000;
lastCheck = timestamp;
return res;
}
function updateStatsEngine(snap) {
// contact keen.io via their REST API
// tell intercom.io that we have an event
// do whatever is desired to store quantifiable stats
// and track billing info
//
//var client = require('keen.io').configure({
// projectId: "<project_id>",
// writeKey: "<write_key>",
// readKey: "<read_key>",
// masterKey: "<master_key>"
//});
//
//client.addEvent("collection", {/* data */});
}
The downside of this approach is that if my admin script goes down, any events during that time are not logged. However, the wonderful thing about this script is its simplicity.
It's not going to have many bugs. Add monit, upstart, or another tool to make sure it stays up and does not crash. Job done.
It's also highly versatile. I can run it on my laptop or even my Android phone (as an HTML page) in a pinch.
Let's take the example of http://up2f.co/15euYdT where one can secure the firebase app by checking that only the creator of a comment can change a comment.
Let's assume that we need to keep in another structure the total number of comments, something like
"stats" :{
"comments":{
"count":2
},
}
We need to protect this part from direct access from registered users.We could do something like
"stats" :{
"$adminid":{
"comments":{
"count":2
},
},
}
where we could only allow an admin to have access there.
To do this we would need to create a persistent connection to Firebase that would listen to changes in the comments table and would trigger an event to update the stats table.
Is this possible? If not how else can we secure data that is not assigned to a specific user?
Since your admin process will use a secret token to log in, security rules will not apply. Thus, you can simply secure client access using:
// not applied to privileged server logging in with token
".write": false,
If, alternately, you wanted clients to increment the amount, you could use the following trick, which only allows them to increment the counter, and only allows them to add a comment if the counter has been updated. (See a working demo http://jsfiddle.net/katowulf/5ESSp/)
{
"rules": {
".read": true,
".write": false,
"incid": {
"counter": {
// this counter is set using a transaction and can only be incremented by 1
".write": "newData.isNumber() && ((!data.exists() && newData.val() === 1) || newData.val() === data.val()+1)"
},
"records": {
"$id": {
// this rule allows adds but no deletes or updates
// the id must inherently be in the format rec# where # is the current value of incid/counter
// thus, to add a record, you first create a transaction to update the counter, and then use that counter here
// the value must be a string less than 1000 characters
".write": "$id >= 'rec'+root.child('incid/counter').val() && !data.exists() && newData.isString() && newData.val().length <= 1000"
}
}
}
}
}