Hey there, hope your having a great day! So in the community I always hear about sanity checks for remote events. I never quite understood how to make sure the events are only being fired from scripts/not from exploits. For example if I have a remote event for making the player fly, how would I apply sanity checks to it. (On mobile rn, so I don’t actually have the fly event, but I can use it later)
If you have an answer to any of the above questions please let me know, have a great day.
You can check for what errors a player creates with invalid data though e.g using pcall, then you can ban them on the spot. The other thing is checking usual stuff like if its a remote thats normally only fired when a player is in a certain area you can check server side to ensure they are indeed in the area.
Also if you are making a player fly as part of a admin script then lock that remote to a whitelist and ban anyone else who attempts to use it. Players can still fly locally so ensure you have a anti exploit to ban players that are flying without permission.
True but thats only due to pcall, they still cause errors if invalid data is put in, its just handled differently by attempting to add a metadata for pcall success and error
You apply sanity checks by basically re-confirming that the player has the right to fire that event.
For example if you make a person fly and that was an admin only thing or a tool only thing, you should check on the server if that person is an admin and/or check if the tool is inside the player’s backpack/character.
In my personal opinion this can get annoying to do especially if you have a game full of very badly secured remote. Like for example, if you send configuration data (like fly speed, fly duration, etc) through the remotes you’ll have to re-verify on the server or the exploiters can change it on the client to go at superman speed and can potentially crash the game. But sanity checks are important so this is something you have to consider whenever you allow a player to use an remote on your game.
Ok, thanks! I’ve noticed that you and many others are suggesting server-sided checks, however for my fly Remote it is client-sided, (eg: FireClient from admin-commands server script). How would I go about that? (and yes I already have admin checks in the server script)
I’m sorry I may sound dumb, I don’t know much about exploits. Is it even possible for an exploiter to FireClient?
So by whitelist i mean like only players on the list can fly whether it be by owning something in game or being a admin and yes players can fly by their own exploits which is why you would use a system like this to only allow people you want to fly, they could still use their exploit to fly if they are on the whitelist but if they are allowed to fly anyway it wont make a difference other than speed which is a controlable and detectable factor.
As for this when a player starts flying fire the server, then the server will know not to ban them when they are flying. (Ties with your anti explioits whitelist). Still i wouldnt advise this without a bunch of checks.
FireClients can only be fired from the server. Only way exploiters can use FireClients is if they used FireServer on a remote event that uses FireClients.
Exploiters are able to control the physics on their own roblox character because physical force is automatically replicated from the client to the server, so they can fly around without having to use the fly script in your game. You’ll probably have to do more than just sanity checks to stop exploiters from flying all together.
Simple antiexploits can solve this issue tho, to list a few, speed checks, raycasting under the character, velocity checks. Also the basic exploits actually print a message into the devlog when a player starts flying which makes one of the api exploits automatically useless
Also to make things easier to understand, a exploiter can access or do anything a local script can do, e.g using modules and remotes from the client side. They cannot use server sided stuff, if they could then even trying to anti that would be pointless
Yeah, thats what I thought, so I shouldn’t have to worry about anyone being able to fire that fly event because it is OnClientEvent which you cannot do from the client.