Multiplayer game security in CloudBehaviours
Lock down CloudBehaviour endpoints with access control, and validate the caller on every call.
Read time 2 minutesLast updated 15 days ago
Important
This page describes an experimental feature that might change significantly before release. It's not recommended to use or rely on experimental features in production environments due to potential instability.
Important
A CloudBehaviour has two halves: a cloud script that runs in the cloud, and a client bindings script that runs in your game. In the cloud script, marking a method public means more than it does in regular C#: every public method becomes a network endpoint that any client, including a malicious one, can call. Public methods that you write in the client bindings script run on the player's device like any other MonoBehaviour method, and don't become endpoints.
Public means a network endpoint, not just C# public
A method you write only for internal use, without thinking about who calls it, is exposed as a callable endpoint by default. A method that times out a player's turn, for example, must confirm it's legitimately that player's timeout, because any client can call it directly.
A timer callback must be public too, because a timer can only schedule a public endpoint. If you make the callback private to hide it from clients, the scheduling call doesn't compile. Keep the callback public, and restrict it with instead. Refer to Timers in CloudBehaviours.
[CloudCodeAccess(Access.Service)]Lock endpoints down with access control
Use to restrict an endpoint to the server, a specific caller, or another behaviour, rather than any client. Refer to Access control in CloudBehaviours for the full list of access levels and when to use each one.
[CloudCodeAccess]Re-validate the caller, every time
Access control decides who can call an endpoint. It doesn't validate what they're asking for. Never assume only the intended player calls an endpoint. A "time out this player's turn" callback, for example, must confirm the timeout is legitimately for that player, and a "submit this score" endpoint must validate the score against server-side game state, not trust the caller's claim.