After witnessing that FE isn’t all that’s needed to protect your game, I’m trying to protect the important lines of code in my game.
local script:
Server script:
I know the code is pretty basic but how can I check the legitimacy of the code on the server? To make sure an exploiters don’t use it for their own gain.
You’ll have to assume it’s always an exploiter that has fired it, so you have to take any precautions and put checks in place for it even if you’re sure it’s your script firing it. Or at least ideally, that’s the practice of FE.
For your specific code-block in OP;
Don’t let the user supply an instance that you simply change the value of. Find valueThing (fightingStyle) yourself, and remove it from the call if possible.
Same for backpack. This is player:WaitForChild("Backpack") or player:FindFirstChildOfClass("Backpack") - hopefully your game doesn’t change the name of someone’s backpack server-side 
And other than that, you can add checks that makes sure you can’t keep old tools if you change fighting style etc., as to prevent mass-spam of that remote, and add in a cooldown if necessary. (this changes the actual behavior of what your code does, instead of just the way you fire the event)
Rule number 1 of security
Never trust anything
In your code you are going to want to put something to check if it makes sense to give the fruit. Idk what you are using this for but an example would be that you would check on the server if the character is close to a fruit giver
Ha…mon?
DID YOU SAY “HAMON OVERDRIVE”?
Make checks on the server, never trust the client.
Treat your remotes as a way for the client to request stuff from the server, not as a way for the client to tell the server what to do. It’s essentially the same thing, simply with the server sided checks to verify that the remote is not abused.
Instead of doing this:
> client tells server the amount of currency it should receive
> server gives the client that much currency
Do something like this:
> client tells server why it should receive currency (Ex. Daily reward cash in)
> server makes sure the client deserves the currency and figures out the number
> if everything is fine, then the server gives the client the money, which was figured by the server, not given by the client
You can’t trust the client, so instead of letting the client fire remotes that execute at will, have them fire the remotes with the action. The server checks that they can preform the action and acts accordingly.
TL;DR: Always put in Server sided checks
I recently made an anti-exploit script that prevents users to gain access to building tools and such. I think this portion of my script could help you in your case, considering that’s what you’re trying to do.
Here it is :
game.Players.LocalPlayer.Backpack.ChildAdded:connect(function(Child)
if Child.Name:lower() == “delete” then
game.Players.LocalPlayer:kick(me.Parent.Name … “, you were just caught with btools. :)”)
print (me.Parent.Name … “, you were just caught with btools. :)”)
end
end)
Hope this helps!
Wouldnt locking every part in game make btools useless?
Using filteringenabled makes building tools useless.
yea that too
Yes, it would, but btools such as F3X allow you to create parts.
And then naming it something other than delete makes that code useless 
Not really. In games like obstacle courses, for example, inserting parts can give you a gameplay advantage since you can walk on parts even if they haven’t replicated to the server.
Having code like that on the client rarely helps, since the exploiter could always delete it, or read it and figure out a work around. You’d be better off just using FE and making sure that there are no big security flaws.
But if you do wish to detect exploiting from the client, I think that’s a fairly bad method. The easiest work around is for the tool to simply be named something else.
If your goal is to stop exploiters from abusing tools, specifically btools, then here is what you can do: