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…
If your game is vulnerable enough to the point where an exploiter can expand hitboxes and it actually does damage, a anti-hitbox expander script should be the least of your worries.
Let the server handle hits.
AOE magic spells / etc is the only time when you should be letting the Server do Hit Reg in my opinion and letting the client do hits is fine if done correctly.
If you do Server Hit Reg on melee and gun type weapons, it results in a noticeable delay between the client’s perception of the hitbox and the Server’s, leading to lackluster and “un-crisp” gameplay, but the problem with using client-side hitboxes is that it becomes literally impossible to stop an exploiter from changing the size of other players hitboxes on their client.
Luckily, you are able to do server-sided checks, to heavily decrease the the effects of this.
I’d do either server sided hit detection or (in my opinion a better solution) client sided hit detection with server sided sanity checks. Client sided hit detection is good because you want instant feedback for the user. But if you don’t take the necessary precautions on the server to make sure the shot is legitimate then things like hitbox expanders can be a problem.
This is usually a few things. (Over simplified here)
Are the projectile paths/simulations somewhat synced?
Did this shot exceed a given budget?
Is it close enough to a limb?
Never rely on client sided anti cheat or security through obfuscation
While letting the client handle important functions is indeed a bad practice, you can still nevertheless rely on it, if implemented correctly.
What I do is have the client check if whatever it’s trying to do is valid first (shooting a bullet etc), before sending it to the server. The server also checks for the same, but what’s changed is that the server doesn’t have to check in all cases; and as the majority of your players wouldn’t be exploiters, it would help against server lag by a lot.
Hot Take: Using a Hit-Box Reducer deserves praise because it makes it harder to hit shots.
You can make your own LocalScript/test a pre-made copy-paste exploit LocalScript if you want to test exploits on your game. No need to use a program to test exploiting. Yes, there are certain things that the client can’t do such as adding things to CoreGui, but things like this cannot be prevented. The only things that can be 100% prevented is things that replicate from the client to the server, and all client to server replication can be tested without using an external program.
Best solution? just send the hit part’s size to the server and check on the server if the size is bigger than what it should be, allow damage if the size is appropriate.
