0

I'm developing a multiplier board game (very similar to Chess). I'm using Firestore as the backend. I understand that to prevent cheating on the game, I need to put the game logic (validate legal moves, change turn, countdown timer) on the server-side and not on the client-side. Now, as I understand there are mainly two places to configure the server-side behavior in Firebase: Cloud Functions and Security Rules. I thought about using Security Rules to validate moves and Cloud Function to flip turn and countdown the time. I don't have much experience with Security Rules, but I think writing rules to validate moves would be too complex. Alternatively, I thought about preventing all write access to the Firestore from the client and writing HTTPS Cloud Functions for the client to call. For example, I would have a function for making a move. The client would call this function instead of writing directly to Firestore. I'm not sure how to go about this. What do you think?

3li
  • 598
  • 3
  • 13
  • This statement isn't accurate *to prevent cheating on the game, I need to put the game logic on the server-side* and not sure where that information came from. If that were true then any data could be compromised. Rules control read/write access to your apps data that's stored in Firebase - they probably are not the right place to validate moves as there would (generally) be logic involved with that which would be handled by the app. e.g. preventing a bishop moving vertically on the board; you could probably pull that off in a rule but that would be better handled by a code level calculation – Jay Oct 05 '19 at 16:20
  • Anyone with enough experience can mimic your client. This is not a problem with Firebase. It is the nature of software. Any accessible software can be reverse engineered with enough time and effort. – 3li Oct 05 '19 at 18:04
  • You might find this answer helpful https://stackoverflow.com/a/40564807/4330274 – 3li Oct 05 '19 at 18:13
  • Yes - perfect answer and speaks directly to what I said *That's why you secure access to Firebase data...(using Authenticaton and) security rules (for database or storage) to ensure they can only access the data they're authorized for.*. Great answer which addresses your question pretty accurately. Check out the follup question & answer as well [How do I prevent un-authorized access to my Firebase Database?](https://stackoverflow.com/questions/18005984/how-do-i-prevent-un-authorized-access-to-my-firebase-database) – Jay Oct 05 '19 at 19:00
  • Okay, so do you agree that we have to put the game logic on the server-side and not on the client? – 3li Oct 05 '19 at 21:15
  • I wouldn't agree that you *have* to put game logic on the server. As mentioned, if someone could 'cheat' by altering the game data then they could alter any apps data at any point; that would make Firebase a very insecure platform for creating apps. Between Authentication and Rules, a client app is very secure. However, it's totally up to your use case - if you want to take on the challenge of controlling game logic via server calls and rules it can probably be done, and would certainly be an interesting test! – Jay Oct 06 '19 at 12:10
  • @Jay You can't be sure that requests to your server are coming from your client. Authentication and Rules do not give you that. So, if you put the game logic on the client, someone can create a new client that can connect to your database and thus bypass every validation you put on your client. It might be hard, but it is certainly possible. Again, this does not make Firebase an insecure platform. It is how programs work. – 3li Oct 06 '19 at 15:31
  • Understood. It may be in your best interest to explore how authentication and rules work (tokens, expirations etc). Also, take a look at the video linked in @frankvanpuffelen accepted answer along with the vast amount of documentation on Firebase Security that's available. The bottom line is you should code it for however fits your use case. Good luck! – Jay Oct 06 '19 at 15:38
  • @Jay I will. Thank you! – 3li Oct 06 '19 at 15:43

1 Answers1

3

As you said, there are two broad options:

  1. Validate the move in security rules.
  2. Validate the move in Cloud Functions.

Since security rules are close to Turing complete, you can express almost any requirement in them. But as your game rules get more complex, you'll see diminishing returns for implementing your game logic there. The declarative nature of security rules is just hard for most of us to get right.

So for more complex game rules I'd usually opt to have a code enforce them, in the shape of Cloud Functions. So in that case:

  1. The client writes a "game turn" to the database.
  2. The structure of this game turn is validated by security rules.
  3. The write operations triggers a Cloud Function.
  4. This Cloud Function interprets the game turn, and updates the game state.
  5. All clients then see the new game state.

Firebase's Doug Stevenson game a good talk showing this approach at Google I/O 2017: Architecting for Data Contention in a Realtime World with Firebase. While he uses the Firebase Realtime Database there (as Firestore wasn't released yet), the same approach applies to Cloud Firestore.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • I would like to add a note to this excellent answer that the broad options 1. and 2. would never be needed if proper Rules are set up in the first place. In other words if rules do not permit access to the data from outside the app, there would be no way for someone to randomly change it from outside the app. e.g. someone couldn't just 'log on' and move the chess pieces around - rules would prevent access to that data. – Jay Oct 05 '19 at 16:26
  • Also note that if Firebase data could be randomly changed (i.e. 'cheating') from outside an app then it wouldn't be a very secure database for apps, right? Rules are meant to allow/prevent read/write access and validate data is what it's supposed to be. – Jay Oct 05 '19 at 16:32