The server shouldn't trust the clients. The clients should just send inputs or actions, and the server will do validation and decide what the result will be.
Autoaim cannot be solved absolutely by technical solutions.
Even if the executable is fully electric fenced and verified matching a checksum, aimbots can just read the video buffer from a different process.
In practice, you can statistically analyze player hit metrics and then monitor people who appear to be too good.
However, this requires basic customer service which is less likely to come from a free server for a noncommercial game.
I don't expect it would be that hard to make an aimbot look human by throwing in some random variation. It would probably then be difficult (even for a human auditor) to reliably differentiate genuinely good players from "too good" players.
It may send the position the player is aiming at at certain periods, if the player is way to accurate and linear moving to the target you can ban him. Some false positives and stuff should be considered too
That's a good first step but it doesn't really stop hackers. Specifically the two cheats that the parent mentions don't require the server to trust the client. There's mitigation that can be done to prevent wallhacks, but aimbot can be really difficult to detect without sophisticated tools, and even then fundamentally the cheat can operate as an intermediary between mouse input and the game receiving that mouse input which makes it impossible to directly detect without memory inspection. Essentially you're left with heuristic analysis of mouse movements, or more likely a "Overwatch" (CS:GO) type system where moderators/janitors are tasked with evaluating players to determine if they're cheating or not.
Cube2, another oldie but goodie FOSS games relies heavily on admins too. They are supported with stats (a server plugin, IIRC) and a observer mode which is actually available to all spectators (the game is more focused on fun than competition).
Cube1 solved the problem by keeping the communication stack closed source so you couldn't build a aerver-compatible client. The OSS version of Cube1 used a different communication stack.
We don't really have the technology to do that completely. Because it's really hard and expensive to stream pre-rendered video at a low enough latency, most action games still transmit player positions and trust the client to accurately render the corresponding video client-side.
Although, even in scenario with a completely untrusted client receiving only final video output, there's no guarantee that the actions being input are human.
