"Your realtime database <xxx> has insecure rules"

[habitoti]

I received a warning email from Firebase, that my (productive for a while already) database has insecure rules, and that authenticated users can read/write the whole database, and thus change or steal data or make costly changes.

This is kind of true, as it's a server-less turn-based game DB, and the app of every user basically can make changes to all parts of it. There is almost no data anywhere that read-only to all users, every move changes something everywhere in data pertaining to a game match and all participating users. Beside the "auth != null" restriction, the only further rule makes sure that a change-set has a +1 version number to the existing version to avoid race conditions.

Until that mail I still felt kind of safe as the only authentication provider is Playstore and Gamecenter oAuth, so given how complicated it is to set those up with all the signing cert stuff ;-) , I thought that really only the app itself would be able to do a proper authentication towards Firebase, and no individual with some other tools (premium hackers aside, that might always do that somehow...). Am I too naive? 

On the mentioned potential of "making costly changes": if that would be the goal of a hacker, I am not sure how that should be prevented anyway unless Firebase would (finally -- sic) offer some hard data growth restriction limits. An authenticated user will always have _some_ area to validly write to, and then he could just fill it up with tons of data.

Regards, habitoti

[Kato Richardson]

Hello Habitoti,

So a few things for you:  You can turn off the errors by making some minor changes to your rules. For example, if the paths off of root are foo and bar, you can do this and you will no longer receive warnings:

{

   "foo": { ".read": true },

   "bar": { ".read": true }

}

This is fine for a hobby project, as long as you understand the risks. You'll probably want to stay on the free plan, or set up budget alerts on your project to make sure things don't get out of hand. At scale, you'll need to carefully think through your schema and the things users are allowed to do, as well as how you will validate access with whitelisted groups, owners, etc.

For a simple strategy to prevent users from writing tons of data, that's just a matter of validating your schema, and probably your queries. For example, you can verify that only the fields you allow are written, and enforce a max size on them. On queries, the simplest answer is to enforce usage of limit. I put together a quick example here.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/e06522be-a52c-4d5b-a537-c268f0854245%40googlegroups.com.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[habitoti]

Hi,

thanks for your answer. We are actually on the Blaze plan, and budget alerts are of course in place. However this wouldn't stop any wild data growth, and we are not on a 24/7 watch for them, tbh.

I am not worried about the app itself at all. The way you (can) interact through the UI won't allow you to do crazy things and produce any data avalanches. That's all very controlled. The only thing I was wondering is whether a Firebase project with authentication being setup only for Play Games and GameCenter OAuth would allow anyone (not being my app) to somehow become a logged-on user and execute queries and upload data. From what I understood that should not work at all, as only my app with its signature should be allowed to do so. 

Thanks for the tip of moving the root rules down to the individual nodes. That I'll do in any case now.

Regards, habitoti

To unsubscribe from this group and stop receiving emails from it, send an email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/e06522be-a52c-4d5b-a537-c268f0854245%40googlegroups.com.

[Kato Richardson]

I don't know much about Play Games Auth, but that seems like it will help.

> the UI won't allow you to do crazy things and produce any data avalanches. That's all very controlled

Then you should take the time to employ the same controls in your security rules.

> We are actually on the Blaze plan, and budget alerts are of course in place. However this wouldn't stop any wild data growth, and we are not on a 24/7 watch for them, tbh.

You can configure email alerts for sudden spikes so you don't have to log in frequently and check your usage. It won't stop wild growth but it will allow you to catch it early and optimize or turn off usage if needed.

☼, Kato

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/6d5aed4b-a6b1-4866-819c-a072526d3e36%40googlegroups.com.

[Hans-Jürgen Richstein]

Thanks Kato, much appreciated!

You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/MRGuOSQoBEE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEaXNj_62W%3Dvk_rnf%2BtDDFgbc53zbiziK2Tx-auJaQrykg%40mail.gmail.com.