When should I be using RemoteEvents and RemoteFunctions

I am making good progress with my project, but keeping the game secure has always been in the back of my mind. I know I will have to make the game secure at some point, but I wasn’t sure how to really do this.

I want to stop now and really iron out any problems I have now before I move on, so I dont fall through the old termite ridden floor later.

When are these used, when are they necessary?

Remote Events/Functions are used to allow the client and server to communicate with one another. Simply put, they allow the client to tell the server to do something and vice versa. With Filtering Enabled being mandatory now, it’s improtant to understand events if you have any sort of player interaction with the game (for input or feedback).

One of the basic principles of security with events is never trust the client. Verify everything it tells you and always be sceptical. Exploiters can fire events with any parameters and view everything you’re doing.

There’s a pretty good summary on the old wiki here

4 Likes

A good start would be to do type checking on every single parameter you accept from the client on the server (except maybe the player parameter itself). Check all of the types using type or typeof, and put constraints on what values are allowed, like always check for NAN on number types, including all 3 axis of Vector3s. If you have something like SellItems(slot, amount) then do bounds checks to make sure slot and amount are within a valid range for that context, like don’t allow negative values in amount.

Another way to secure remotes is don’t let the client specify too much information about an action. If you have a damage system where the client reporting damage to the server is feasible (it almost never is), then don’t let the client say how much damage or who to damage. Infer the damage from stored state on the server.

Bad example:
DamageDealt:FireServer(humanoid, weapon, damage, location)

Better example (could probably be improved still with more context):

AttackedAt:FireServer(location)
-- location is checked to make sure it is a valid value; prevent things like swinging a sword half way across the map
-- hit calculations performed on server; 'humanoid' is inferred from this
-- current equipped weapon is stored on the server; 'weapon' and 'damage' are inferred from this

It is incredibly difficult to go into more detail than this without knowing the exact use case, and learning how to secure remotes on a case by case basis on your own is an intuition you will have to build up with experience. Never stop experimenting with new ways to approach viewing and solving problems.

1 Like