How safe is it to send instances through remote functions/events?

I know some of you might be smacking your heads out there but hear me out, just like the title says. How safe is it to send instances through remote functions/events?

In my game I’m having the client send a model instance to the server which the server then gets an attribute “Cost” on the model to apply to the users Money in their datastoreservice.

Now here’s the part I’m wondering about, if the client somehow manages to fool the server into accepting a fake model instance, this could potentially break the game as now I have a ton of players that suddenly get a huge amount of money out of nowhere.

Should I opt for a more secure and also more complex method or trust that the roblox engine would reliably do its job on this?

Well one thing that might get in your way is that it is simply not possible to send instances that have not been replicated through remote events/functions.

This means you cannot use FireClient with something in ServerStorage (or any other Server only container), and you cannot use FireServer with something created from the client. If it exists on both the server and the client then you can send it over, but any changes the client made to the instance on their client will not be accepted by the server unless the client has network ownership over the instance itself.

But why not just get the cost from the server? Without going too much into detail, in the game I’m working on the cost attribute is applied from the server, so any changes the client makes to it will have no effect and only the server can change its value.

5 Likes

Well the model is a tycoon plate, by giving the tycoon plate an attribute of “XXX” something. It makes it an easy place to get “XXX” since it’s just getting passed through a remote function. I can also change it without having to go through the workspace or coding.

Not to mention that when I work I place these tycoon plates around the map which the player can step on.

In summary: Readability

If the object exists on both the server and client, you are passing a reference to an object that won’t change on the server. This kind of networking paradigm you’re suggesting is implicitly secure because exploiters shouldn’t be able to generate objects that properly get passed through the remote; objects generated by the client should pass nil as stated by @steven4547466.

1 Like

Please note that “anything coming from your client will not be secure. It doesn’t matter how clever your system looks, or how much time it took you, you’re not the one in control of your client. If it makes you sleep better at night, the extra headache is okay, but you should not be relying on it to ever really work.” (Exploiting Explained)

Remote r exploitable since it’s in the client. In my opinion, thinking about what if the client somehow manages to fool the server into accepting a fake model instance is just a waste of time. However, if u use the remote correctly, it will be totally secure.

1 Like

Yours made a lot more more sense, i’ll give him a heart.

If you’re passing instances you should always typeof check that they are instances on the server, maybe even IsA and check parent too to ensure no other instance or an instance-like table is being passed to the server.

If you want to avoid that altogether, just tag all your related instances server side and let the client send a string corresponding to a tag you know definitely exists.

4 Likes