The answer is yes, and you cannot really prevent it, other than attempt to mitigate it with an anticheat (which will be bypassed eventually).
Never trust the client with important data. Only data you can rely on is client’s inputs. Everything else should be handled/stored on server-side and passed down to clients, not the other way around.
Now I know this sounds very generic, but pretty much everything has to be reviewed on a case-by-case basis.
For example here it looks like you are passing some kind of inventory of items from client to server. I’m kinda gonna assume the client has his own local savegame, with his inventory, and whenever he connects to server he sends all his items (I can only guess). Well if that is the case, there are several attack angles :
-
cheater can manipulate his own local savegame
-
cheater can manipulate items in game memory before they are sent to server
-
cheater can forge AddItem calls with custom data.
Solution would be to make sure all items manipulation (pickup/drop/etc) are done by server, and store the savegames on server (yes, for all players). As per what I said above, server can’t trust the player saying he has X item, but server can trust that he has pressed “F” while he was in radius of an item (overlap events do work on server) - server manages inventory, and stores everything.
RPC validation can only do so much, sure you could use it to validate that Quantity > 0 and Quantity < “a reasonable value”, but that won’t really do much.
If you have enough data on server to validate that the arguments sent by client are legit, then you can probably initiate that call from server and don’t need the client to do it.
Now maybe I’m assuming wrong and your use case is totally valid, like for example the client is interacting with a chest and decides items stacks from inventory to store into the chest, so the client is sending ItemClass+Quantity to store. In that case, if server can validate that client actually owns Quantity of ItemClass, then RPC validation should do the job just fine.