Are key systems for RemoteEvents helpful?

So this would trigger a remote event called “FireLabel” and send a secret key

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local FireLabel = ReplicatedStorage:FindFirstChild("FireLabel")
local secretKey = "A9DI8DJ39SLAJD93I"
FireLabel:FireServer(secretKey)

The following is the reciever that will check if the key is correct and if so it will continue on with itself

local ReplicatedStorage = game:GetService("ReplicatedStorage")

ReplicatedStorage.FireLabel.OnServerEvent:Connect(function(plr, key)
	if (key == "A9DI8DJ39SLAJD93I")then
           --Do stuff here
              Print("Does this key system do anything?")
       end
end)

Would this system work to prevent exploiters from triggering events?

Exploiters can look into the localscript and steal the Key. So. its not secure

What if I stored the key in ServerStorage under an IntValue? … and I just realized local scripts can’t access serverstorage :confused:

You would have to access it through another remote, so no. “Passwording” your remotes is a type of security called security through obscurity, which is not security in the first place. Instead of trying to prevent exploiters from firing your remotes, make that be useless because you have proper sanity checks.

As @sjr04 said, best way to protect your game from exploiters would be throught sanity checks, in your server script. The rest can always be bypassed (from what I learned, could be wrong).

LocalScripts and ModuleScripts can always be decompiled by an exploiter unless they are not replicated to the player. There are more advanced remote key systems that involve encryption that stop exploiters and there are tools that you obfuscate your code making it extremely difficult to find RemoteKeys, but exploits also allow for exploiters to see the contents of all RemoteEvents being sent, so even if you try to hide your remote key it doesn’t matter.

Server side sanity checks are the way to go.

No, I don’t think keys would be helpful. It is possible for exploiters to read the code. The best solution is to have the server in full control.