back
2 comments
I came to the same conclusion that Kiro did when I evaluated Firebase a few months ago that I would always end up needing some server-side validation even with the authentication and security rules but I think I just noticed something useful.

Apparently you can get the actual data being used when writing the rules expression by using the `val` function[0] on the `data` variable[1]. However, your docs called the rules expression "Javascript-like"[2] which makes me wonder what limitations exist on the expression syntax. Since I can call `val` to get the primitive value, can I use Javascript functions/properties on those primitives like `length` on arrays?

Here's a use case, given an object that looks like

    { name: "Adam", family: { spouse: "Eve", children: [...]}}
Will the following expression work to limit changing the name of the spouse if there are more than 1 element in the children collection:

    "$spouse": {.write: data.child("family").val().children.length < 2}
Not quite sure if you can write a rule for a property within an object but if the above works, then the rules system is pretty damn awesome :)

[0] https://www.firebase.com/docs/security/rulesdatasnapshot/val...

[1] https://www.firebase.com/docs/security-quickstart.html Ctrl+F "We use the "data variable"

[2] https://www.firebase.com/docs/security-quickstart.html Ctrl+F "We use the "Javascript-like"

Thanks but I don't see how security rules will prevent someone from manually setting their own score. Take your 404 Astroids game as an example. Right now anyone can set their own score as they wish. Is there a way to prevent that using security rules?
You can enforce this as well as any other backend can. Games are a bit of a special case because you not only want to enforce access controls and a particular data model, you also want to make sure the client didn't "cheat".

It turns out this is an issue with any game that runs on the client though -- regardless of if you're using Firebase or not. Preventing cheating is tough because at some step in the process here you're relying on the client to tell the server the truth. Since the game runs on the client, you can't ensure that the code hasn't been tampered with, or that an AI isn't playing the game, or that the user hasn't cheated is some other way.

With Firebase security rules, you can enforce that only that user can set the score, and you can enforce that the score is of a valid format, but fundamentally there's no way to ensure that the score is "real".

No, but you can make it much more difficult by passing something like a frame of the game state, where some variables (like Timer) are passed in plaintext, and others (which are calculated in an aggregate way at runtime, e.g. can't be easily guessed) are hashed for double checking by the server. Of course double-submission is still an issue, but nonces and server-side duration checks should help you here as well. Compress the &*!# out of your source and.. it will at least take an attacker a lot of time to break.

afaict (would loved to be proven wrong here) Firebase gives you basic protection but any script kiddie will still be able to defeat it.

Edit: grammar

When you say 'game that runs on the client' -- I'd clarify that you're talking about the authoritative game logic.

Ie most multiplayer games ship the same physics code on client and server, but the server is the authority.

That kind of game is clearly impossible with Firebase, but depending on the expressiveness of the validations, there might be ways to prevent cheating.

    allow update of y_pos IF jump.pressed 
    AND not jump.wasPressed 
    AND new.y_pos - old.y_pos < 3 
    AND old.was_on_top_of geospatial( world_geometry, entities)
    AND new.not_inside geospatial( world_geometry, entities)