Hello, so I’m wondering what are some ways of making remote events more secure and reliable.
I’ve heard of the “Leaky Bucket” method but I’m still confused on that so could anyone give me a short example and explanation? And are there any other ways? Should you use different ways of securing a remote if they fire it very fast normally, like 3 times per second, or longer ones like once every 3 seconds? I’m not asking for scripts, I just want a solid understanding since I’m better at learning from examples. I’ll take anything such as range checks, etc. Thanks!
1 Like
I’m rather sceptical there’s a sure-fire way to secure remotes because exploiters always find workarounds to anti-exploit methods. Best practice would be to put everything important on the server side; don’t trust clients with handling things like calculating the amount of money one receives after completing a task. Put crucial values on the server side too and force your client to make calls to get those values for things like GUIs.
Thank you I always try to do multiple checks it ends up filling the if statement lol. But how would you approach a server sided denounce?
How you need to secure your remotes is situational in the first place, so without a specific use case it’s difficult to provide you any actual advice other than general tips and methods of security. Without a specific goal in mind, an information dump isn’t very productive to have.
There are many ways you can picture this practically, so imagine a keycard-locked door. The keycard is the client and the server is the card reader. By sliding the keycard, firing the server, you are sending over a packet of data and requesting that the reader, the server, accepts your card and opens the door. The reader checks this data packet, the arguments sent through a remote, and lets you through if the credentials are sufficient, the server clears all checks without issues, or not if your credentials are insufficient, dropping the request (can be done with a guard clause in remotes if you fancy).
1 Like
I am aware this is a older topic but here is how a Server-Side Debounce could be done.
In this server-side script you can have a table and put the player’s Name/UserId (You decide) when the debounce is active for that player then have a wait for how long you want it too last after you have done what you want todo then remove the Players Name/UserId from that table.
It can work something like this:
local SERVER_DEBOUNCE = {}
[Event/Function Firing]:Connect(function(Plr)
if SERVER_DEBOUNCE[Plr.Name] == nil then
SERVER_DEBOUNCE[Plr.Name] = true
-- Do Stuff
wait(.3) -- Change this is you wish.
SERVER_DEBOUNCE[Plr.Name] = nil
end
end)
I hope this helps, Zonix.
1 Like
This is a bit late but what I do is instead of creating remote events and placing them in a folder somewhere on the server which is vulnerable to attacks, I create the remotes when the player first joins and then put them in a table and then name all of the remotes blank so that a hacker won’t know what is what, however, my scripts will. The downside is that you have to use the remote handler for EVERYTHING but the upside is that nobody will be able to figure out what is what. I have Synapse X for testing purposes and this seems to work. This method makes it impossible for a malicious user to send a “fake” request to send/receive data that they shouldn’t
2 Likes
I’ve actually seen this multiple times and would like to learn more about it. I can understand how it would work from the server, but how would clients identify a remote that they want to fire?
There might be a way to secure remote events from exploiters, but exploiters can see them and their location with DarkDex
When the user first joins the game, the Remote Events’ names are “scrambled” or made a blank name and put into a table. The client has a script that will store this table full of the remote events and their names.
The server already knows what is what because it does the same when the user joins, just on the server. It’s like having a dinner party where food (data) is passed back and forth between people (remote events) and the the dog (the exploiter) can’t have any 
1 Like
I’ve never heard of the “Leaky Bucket” method but what I’m going to explain to you is what you will see everywhere, it’s called a Sanity Check.
Sanity checks are basically checks on the server to see if whatever the client is showing is actually real.
For example, the exploiter fires a RemoteEvent with the parameter as a Model in workspace when it’s supposed to be a player instance.
On the server, the script uses the playerToAddCash parameter passed from the client to add their cash:
remoteEvent.OnServerEvent.OnServerEvent:Connect(function(player, playerToAddCash)
playerToAddCash.leaderstats.Cash.Value += 100
end)
However, since what the exploiter passed is a model, the script will return an error that goes something like “leaderstats is not a valid member of Model” because it expected a player.
To do this, you do a Sanity Check on the server so that it won’t error:
remoteEvent.OnServerEvent.OnServerEvent:Connect(function(player, newName)
if not game.Players:FindFirstChild(newName) then print("This isn't a player") return end
playerToAddCash.leaderstats.Cash.Value += 100
end)
I think the best way to secure remote events is just give less permissions and use local scripts with remote events to give only local data like mouse