I don’t see the problem with using a LocalScript as one way to prevent this. Like yea, they can disable it, but most exploiters on Roblox are script kiddies and won’t know to do that.
Edit: OH but wait… It does sound like you may be handling your hit detection on the client 
so nevermind
The script kiddies will just be copying someone else’s script that works for your game. It only takes one person to figure out your script can be deleted before just any old exploiter can do it.
I will be quoting @PhantomVisual from his PVEye module (which is a decent client side Anti HBE and a very good spectate tool) for a possible server side solution:
DEVELOPERS:
I DO NOT RECCOMMEND USING THESE [client side] METHODS TO STOP EXPLOITING
I want to tell you the correct way to actually do it:
Store positions of players on the server with a time stamp
Once someone lands a shot, send the time stamp to the server
The server will compare the shooter’s position and the hitPerson’s position to see if the shot was possible
The server will register the damage based off this information
This wouldn’t help against lagswitches but it’s a good start.
Oh the creator of PVEye…yes his tool actually is very good. It logs both false positives and true HBE cases. If the target hits non-existing target according to his module, then that’s a false positive reading, but if it comes back with telling you what the client-side sizes are, then it’s almost gauranteed to be a HBE.
That method PhantomVisual suggested…would solve HBE but possibly aimbot too. I see he made a good amount of progress in trying to take down aimbot and esp, but gave up because Roblox and the server to client latency was too unreliable to avoid false positives on something that requires a lot of careful precision. + And…no one’s ever implemented what he stated because it’s way too difficult, if there’s at least a simple example out there about a simple gun utilizing his method then aimbot and HBE might be put to rest.
This is a super redundant argument you have going, and have not provided a reason why client would be a good permanent solution. Simply put: there is no reason.
It’s actually very easy to use the server for damage and hitreg without having be super precise. I do this myself in all of my FPS games, and after working out smaller issues, have gotten it to work well. Games like Arsenal and Games Unite also do server-sided hitreg.
It’s blatantly obvious you have no idea what you’re talking about, and the topic has so much misinformation that can harm a game. Many users here including BanTech, rogchamp, and myself have years of experience and we know from that experience that the client can’t be trusted.
As such, it strongly recommend you take down this post.
Footnote: I’m actually the guy you linked in the original post, which is why I’m here in the first place. If you would have read that topic and the replies in detail, I seriously doubt you would have made this post.
Arsenal does not have serverside hitreg. But arsenal is a bad sample for this scenario anyway.
Tbh, I know where he’s coming from, though I ain’t sure why there’s this all-or-nothing attitude when it comes to anticheats for some people around these forums. 
I mean, yes, my solutions aren’t as good but, even as a beginner…I’m able to curb a lot of cheaters, if I stuck with an all-or-nothing type of thinking I mean, the game would be much worse off. Like, it should be about mitigating it first, then developing the complex server-sided hit register checker, you can give yourself time and reduce the number of cheaters and then work on the complex solution.
I think instead of him coming off as superior and advocating for the removal of this post because I can’t give the absolute best way to patch this issue (which there have been 0 posts like this which discuss what hitbox expanding is overall), a better way would be to come to an understanding as to how to get a handle on it for now and then slowly start replacing client-side anticheats with server-side ones to stop it almost completely.
So let me explain what he’s angry about. You, a fairly new scripter from what i can tell from this post, made a post about an important topic, anticheat. Now this topic may mislead some people.
Never promote clientsided anticheat. No matter how safe it is, it can be bypassed.
I pretty much solved this HBE issue (cut down its occurrences by about 90% haven’t heard or seen reports if it anymore, very rare).
I totally liked learning about the hit register thing on the server, though currently gotta get more experience to eventually implement that. In the meantime, I seek to offer an understanding about what this even is since this is a topic that’s barely been talked about in detail - but my less-than-desirable ways of handling it aren’t meant to insult the better initiated here. 
In the end, I hope to have given everyone a better idea as to what this is as a whole and clear up common misconceptions.
@ScripterWaffle Whoops, my bad. I’ll keep my mouth shut for that 
@Matrice I should clear up that I’m not angry here; text, even with formatting, makes it hard to deliver a proper tone. Hope you can understand
I’ll make a post in the near future about HBE prevention, anti-fly, anti-humanoid-changes, verification and more. The post will also include a free anti-exploit script to stop some of these, using a method called “network rubberbanding.”
Ah? Then good! Please fell free to link to here if you want! Hey, I did do a good job visually showing what this is and explaining it at the least. This is a topic that people been asking about that the dev site doesn’t talk about, no one out there talks about proper or the best HBE prevention.
Yeah network rubberbanding…so I guess 1 idea I had for that was getting the pings of the client, then use that to exclude pings above 450 where false positives would happen at.
yeah, anything client sided regardless of the effort you put into making it secure can be exploited. there is a solution to every problem and even through the use of remote events, plugins, or whatever, data has to be sent from the client to the server and that can be modified through script injectors (synapse or other stupid exploits). hence, you can limit the mindless script kiddies (people who copy other scripts and paste them hoping they work on the game) and slow down the people who are actively trying to harm your game (by hbe or whatever else they can find). (also, try not to use so many while true loops with a wait, they’re not that efficient and they should be used sparingly because they can eat up the memory of the client and we never know what the client’s computer can handle, try using a chain of quick remote events of a server-sided function call. also, try to randomize your kicks or bans to a minute or five seconds you detect them cheating so it would be more difficult to figure out the fine line to not getting caught).
But exploiters can’t change other player’s body parts’ size on the server side, right? Or am I missing something. I thought they could only change things client side and it wouldn’t replicate to the server.
Nope. They can only change the size on their end, but this allows them to hit their opponent with guns or swords. If you run a hitbox expansion code on Roblox Studios as the developer of a game, you will slide around and the boxes will be seen by all players.
Hitbox Expansion is just a client-side cheat but when the player hits it, they only send to the server that they still hit the other player.
If you doing client side hit detection then you must properly verify it on the server before damaging the player.
Ah, you’re doing client side hit detection. I’ve always heard it’s better to do anything important on the server so exploiters can’t interfere.
The developer of that module you suggested, literally says (in the code) that you shouldn’t use it:
I did a brief audit of the module as well, and it seems like you can create false logs to get other people in trouble. Really wouldn’t recommend this and just use server verification like everyone else has said.
This module is also ridiculously easy to bypass, It’s not even effective.
It has been very useful though, you ought to give it a try sometime, go into a shooter game and have a friend hitbox expand you, then shoot you and see the logged readings, it has been able to return the correct “irregular sizes” that the client hit you with.
The unreliables are the ESP/Aimbot and latency readings from the hitbox expander. I mean, this tool has been very beneficial, not necessarily something to completely discard because it’s not perfect.
The false logs are when it says that the player “hit unexisting target”, but when it actually returns that the player hit a target and returns the client side {5,5,5} for example, yeah those have always been accurate. People who know this tool’s false positive readings from true readings would know the difference between false readings and true ones.
I ain’t doing client hit detection, but that’s something others can do. But, you can’t stop hitbox expansion without many false positives by solely and only relying on server scripts, this kind of issue has to rely on some client input. Server checks like checking the size and restoring it would be great but, this is why client-scripts was a thing I brought up, the server sometimes can’t see it, unless you do the almost-impossible to implement…bullet to server check…which would overload remoteEvent spam the server if tons of players are shoot and the server gotta check if every bullet is legitimately hiting…
