Authoritative Servers and Anti-Cheat

Why Browser Games Need Authoritative Servers

Web games have a unique security problem compared to native multiplayer games. In a native game, cheating requires reverse-engineering compiled binaries, injecting code into running processes, or modifying memory at runtime. These are non-trivial tasks that require specialized skills and tools. In a browser game, the entire client source code is available through the developer tools console. Any player can open DevTools, read the JavaScript source, modify variables, call functions, and send arbitrary messages to the server. There is no code obfuscation that survives a determined browser user because the JavaScript engine must ultimately execute readable instructions.

This means any game logic running on the client is untrustworthy. If the client calculates damage, a cheater changes the damage value. If the client determines collision, a cheater disables collision detection. If the client reports position, a cheater teleports anywhere on the map. The only solution is to move all game-critical logic to the server, where the player cannot modify it.

An authoritative server runs the full game simulation. It processes physics, collision detection, damage calculations, inventory management, scoring, and win conditions. Clients send their inputs (button presses, mouse movements, action requests) and the server applies those inputs to the simulation according to the game rules. The server then sends the resulting game state back to all clients. A client can send any input it wants, but the server validates it against the rules before applying it.

What the Server Must Validate

Every piece of data a client sends should be treated as potentially falsified. The server must validate each input against the current game state and the game's rules.

Movement validation. When a client sends movement input, the server applies the movement using the same physics and speed values it defined. If a player's maximum speed is 5 units per tick, the server moves them at most 5 units per tick regardless of what the client claims. The server also checks collision with walls, obstacles, and boundaries. A speed-hacking client might send inputs that imply moving at 50 units per tick, but the server caps the movement at the legitimate maximum.

Action validation. When a client requests an action (firing a weapon, using an ability, picking up an item), the server checks whether that action is legal in the current state. Can the player fire? Is their weapon off cooldown? Do they have ammunition? Are they within range of the target? Is the item actually present at the location the client claims? Every action is a request, not a command. The server grants or denies it based on its own simulation state.

Rate limiting. Even with proper validation, the server should limit how frequently a client can send inputs. A normal player might send 20 to 60 input packets per second (matching the game's tick rate). A bot or cheating script might send thousands. Rate limiting protects the server from processing overhead attacks and prevents exploits that rely on sending actions faster than humanly possible.

Timing validation. Inputs should be timestamped with the server tick they correspond to. If a client sends an input claiming to be from 10 seconds ago, the server should reject it (or handle it through lag compensation with strict limits). Inputs from the future are always invalid. Inputs that are too old are either rejected or processed with constraints that prevent exploitation.

Common Cheats and Server-Side Defenses

Understanding the most common cheating techniques helps you build appropriate defenses.

Speed hacks attempt to make a player move faster than allowed. Defense: the server enforces maximum movement speed per tick. No matter what input the client sends, the server caps the resulting movement at the defined maximum.

Teleportation sends a falsified position to the server. Defense: the server never accepts position reports from clients. It calculates position from inputs using its own physics simulation. A client that claims to be at position X,Y is ignored because the server knows where that player actually is.

Wallhacks in web games involve reading server-sent state data for players that should be hidden (behind walls, in fog of war). Defense: implement server-side interest management. The server should only send data about entities that a player can legitimately see. If player A cannot see player B because of a wall, the server does not include player B's position in the state update sent to player A. This is called server-side visibility culling, and it is the only effective defense against wallhacks.

Aimbots automate aiming to achieve perfect accuracy. Defense: this is the hardest cheat to detect because the inputs themselves may look similar to skilled human inputs. Statistical analysis can flag suspicious accuracy rates (hitting 95% of shots over hundreds of rounds is statistically improbable for a human). Some games add small random deviations to weapon accuracy on the server, so even perfect aim does not guarantee a hit.

Packet manipulation involves modifying network messages between the client and server. Defense: binary message protocols with strict schemas reject malformed messages. The server should validate that every field in every message is within expected bounds and that the message structure matches the protocol specification exactly. Any message that fails validation is discarded and the incident is logged.

The Cost of Server Authority

Authoritative servers come with tradeoffs that you should understand before committing to the architecture.

Latency. Every player action must travel to the server, be processed, and the result must travel back before the player sees it confirmed. Without client-side prediction, this round trip adds 50 to 200 milliseconds of delay to every action, which feels sluggish. Client-side prediction (covered in the lag compensation guide) mitigates this by showing the predicted result immediately on the client while waiting for server confirmation, but implementing prediction correctly is complex.

Server CPU cost. Running the full game simulation on the server means the server needs enough CPU to process physics, collision, AI, and game logic for every active room. A simple card game might host 200 rooms on a single server. A physics-heavy action game might support only 10 to 20 rooms on the same hardware. Your hosting costs scale directly with the complexity of your game simulation and the number of concurrent rooms.

Development complexity. You must implement the game simulation twice, once on the server (the authoritative version) and once on the client (for prediction and rendering). The two implementations must produce identical results given the same inputs, or prediction will desync and cause visible rubber-banding. Sharing code between server and client (possible in JavaScript since both environments run the same language) reduces this burden, but differences in timing, floating-point handling, and execution order can still cause subtle divergences.

Implementing Server Authority in Practice

Start by identifying which parts of your game state are security-critical and which are cosmetic. Security-critical state includes player position, health, score, inventory, and any data that affects game outcomes. Cosmetic state includes particle effects, animations, UI preferences, and decorative elements. Only security-critical state needs authoritative server processing. Cosmetic state can be handled client-side without risk.

Structure your server code around a command pattern. Each type of player action becomes a command class with a validate method and an execute method. The validate method checks whether the action is legal given the current state. The execute method applies the action to the state. This separation makes it easy to add new actions, test validation logic in isolation, and maintain clear boundaries between input processing and game simulation.

Log suspicious activity rather than immediately banning players. False positives happen, especially in edge cases with high latency. Track metrics like input frequency, movement speed violations, accuracy rates, and impossible state transitions. Flag accounts that consistently trigger anomalies for manual review. Automated bans based on single incidents are risky because network lag, bugs in your validation logic, or unusual but legitimate play patterns can trigger false positives.

For games with ranked or competitive modes, consider recording full game replays on the server. Store the sequence of all inputs from all players along with server tick timestamps. Replays can be analyzed after the fact to detect cheating patterns, investigate player reports, and train detection algorithms. The storage cost is minimal because input-only replays are typically a few hundred kilobytes per match.