While your current rules do their job, they don't protect your database from abuse, which is why they are marked insecure and you get the alert. These alerts are important and shouldn't be ignored without good reason. As @puf mentions in the comments below these alerts can be disabled, but I would not recommend it for your application.
As some examples of attack vectors, you could do the following with your current structure:
- Empty
/user-states
and fill with garbage - which may break your client-side logic
- Change a user's state to something unexpected (e.g. non number, invalid enum value) - which may break your client-side logic
- Change another user's state without permission
- Write megabytes of data to the database - which may break your client side logic
Because your structure seems to be /user-states/$uid = <numeric status>
, you can at least tighten your rules accordingly to:
{
"rules": {
"user-states": {
// any signed-in user may read states
".read": "auth.uid != null",
"$uid": {
// only the concerned user may update their own state
".write": "newData.exists() && auth.uid == $uid",
// state must be numeric
".validate": "newData.isNumber()"
}
}
}
}
If these are too restrictive, you could also use the following which is marginally better than your original rules:
{
"rules": {
"user-states": {
// any signed-in user may read states
".read": "auth.uid != null",
// any signed-in user may update the state of another user
".write": "newData.exists() && auth.uid != null",
"$uid": {
// state must be numeric
".validate": "newData.isNumber()"
}
}
}
}
Note: You could further restrict the new state value to a handful of values rather than just "is a number".