Multiplayer game security in CloudBehaviours
Understand why every public CloudBehaviour method is a client-callable endpoint, and how to restrict and validate calls to it.
Read time 2 minutesLast updated 12 days ago
A CloudBehaviour has two halves. The cloud script runs in the cloud, and the client bindings script runs in your game. In the cloud script, 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 method, and don't become endpoints.
MonoBehaviourTreat every public method as a network endpoint
Cloud Code exposes every public method in the cloud script as a callable endpoint, even a method that you write only for internal use.
A timer callback must be public too, because a timer can schedule only 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 access to it with instead. Refer to Timers in CloudBehaviours.
[CloudCodeAccess(Access.Service)]Restrict access to endpoints
Use to restrict who can call an endpoint, rather than allowing any client. For example, allow only the session host, or only non-player callers such as timers and other CloudBehaviours. For the full list of access levels and when to use each one, refer to Access control in CloudBehaviours.
[CloudCodeAccess]Validate every call
Access control decides who can call an endpoint. Access control doesn't validate what the caller asks for. Never assume that only the intended player calls an endpoint.
For example, a callback that times out a player's turn must confirm that the timeout applies to that player. An endpoint that submits a score must validate the score against server-side game state instead of trusting the caller.