Possible security problems with weapons and abilities

[sagathian (saga)]

the main problem is security problems which come with optimizations.
please let me know if my worries are a bit far fetched.
i will attempt to explain the best i can!

first lets go over simple principles that i am attempting to adhere to
1 - lessen the load on the server to improve performance throughout
2 - do vfx, animations, hitboxes on the client (with necessary sanity checks on the server, more on that)
3 - still use the server to handle important logic that needs to be guarded against exploiters (status such as InAction, WeaponBlocking, HyperArmor, etc…)

heres the pipeline i plan on following
client: handles / listens to inputs
client: input forwards it to weapon module (client based) when correct tool is equipped, client sends request to server to create InAction status for character
client: handles weapon logic and vfx (combo logic, animations, keyframe reached - hitbox)
client: sends hitbox to server
server: verifies hitbox is somewhat legit (distance / magnitude checks)
server: if legit, hitbox checks the status of players (blocking, hyperarmor, blah blah) and operates based off outcome (damages, etc)

i’ve noticed there are a few security flaws that i can’t wrap my head around

1 - how do we check if the player is even using the correct weapon module?
is it sufficient enough to just check the current animations of the player, and see if they line up? i know the hitbox shouldn’t be an issue as the server will know the correct weapon. this also applies to abilities (assuming we’re doing all the vfx on the client), what kind of anti cheat methods would be sufficient? checking the current players data and seeing if the ability animations line up to that which they have currently equipped?

2 - to what extent should i worry about statuses being server sided
i understand i can add a debounce so the remotes don’t get flooded, i can add cooldowns to stuff like blocking and make it so they can’t block everything (posture and what not). however what is the point of these security additions if a client has network ownership of their character and can just move out of stuns with exploited speed?
i know i can do continuous checks to make sure you’re not above a certain speed, but to my understanding there needs to be a margin of error, so if roblox physics glitch out and fling you, you aren’t immediately kicked / banned

3 - should i even be worried about performance like this?
i don’t ever plan to exceed a player cap of 25-30, however as I’ve never made a game before I don’t know how harshly the server gets affected by putting more responsibilities on its back.

every way i see it, theres always some major security flaw / draw back to making it server sided or client sided.
i guess the all in one solution is to have a moderation team.

[red4erik]

1. You should not check the animations of the player on the server as a method of verification, as the client can load and play animations, which would be a vulnerability allowing a bad actor to use abilities/items they have not equipped. You should instead be sending a remote event to the server saying that the player equipped an ability/item instead and just check that rather than animations.

2. This is a complicated question, given that popular games vary in terms of this in just sprinting. (some games have the server set your walkspeed whilst others have the client set it). You need to address the advantages and draw-offs when it comes to movement-based statuses and determine how you want your combat to feel. To address your particular concern, these security additions exist to prevent exploits to would make the game otherwise unplayable if a bad actor determined it to be. For example, hitbox sanity checks: they prevent someone from just killing everyone from anywhere they want. Now, the worst case scenario when a cheater joins is not that the entire game is unplayable, but instead only unplayable against that one person. In the case of having statuses on the server, it’d help prevent hidden cheats that compromise play in competitive environments, as well as making it not entirely unplayable against a cheater (allowing you to outskill cheaters!). The downside to this is responsiveness on the client, and variable status effect lengths. When it comes to stun, you might be able to set the network ownership of the character to the server to mitigate this, or do continuous checks as you said. Don’t be afraid to make a trade-off like server hitboxes as well, lots of popular games and smart developers still use them in PVP applications and their games function well!

3. You should always be worried about performance, but know that simple math calculations are not going be what hurts your performance. Network performance should be of your upmost concern in this case, so you should always aim only send necessary information between the server and client.

4. Moderation team is not an all-in-one solution! They are fallible as they consist of humans and are prone to many issues, and are not a complete safeguard against cheats either. It really depends on the game you’re making whether one is necessary or not, a FPS game will generally need one because sanity checks are difficult when you mess with ranged weapons. However, they would allow you to place more of the burden on the client and thusly gain the benefits which come from doing so, but don’t treat it as a desirable solution.

[sagathian (saga)]

thank you for taking your time to respond
i’ll keep these in mind moving forward :^)