Server-Authoritative Anti-Cheat: What Your Server Must Validate

Your server must validate every action that changes shared truth: movement against time and speed bounds; shots against authoritative geometry and rewind state; cooldowns against server clocks; inventory and currency as atomic transactions; purchases against provider receipts; and match results against a server-owned session. The client may predict the result for responsiveness, but it must never be allowed to declare the result.

If you ship a multiplayer game with anything worth cheating for - a ranked ladder, a shared economy, a leaderboard - someone will eventually probe the trust boundary. Client anti-cheat can raise the cost of tampering on a player's machine. A server-authoritative simulation limits what that machine can turn into shared game state, while a server-authorized backend limits what it can turn into durable economy/progression state.

This article is about that trust split. It is not an argument that server authority replaces Easy Anti-Cheat, BattlEye, reports, sanctions, or behavior detection. Those products and systems operate at different layers. The architectural goal is narrower: a compromised client should not be able to turn an arbitrary local value into authoritative shared or persistent truth.

The original sin: trusting the client

Many deterministic multiplayer exploits start with the same design mistake: letting the client commit a state transition that should have been decided elsewhere. Client-authoritative movement enables impossible position claims; client-reported damage enables impossible hit/damage claims; client-owned economy or inventory writes enable fabricated grants and duplication races.

This is why the foundational fix is architectural, not a product you bolt on. In a server-authoritative model, the client is a privileged spectator: it sends inputs (move forward, fire, place block, buy item) and the server runs the real simulation and tells everyone what happened. The client never gets to declare "I hit you" or "I now own this item". It asks. The server decides.

Notice what this does to the cheat author's job. With client trust, the cheat just lies and the lie becomes reality. With server authority, the cheat can lie all it wants - but the server checks the claim against the rules of the world, and rejects what's impossible. The exploit surface shrinks from "anything the client can imagine" to "things that are individually plausible but statistically suspicious", which is a much smaller and much more detectable space.

What server authority actually validates

"Server-authoritative" is not a slogan, it is a set of concrete checks the server runs on every inbound action. The useful mental model is: the client proposes, the server disposes. Here is what disposing looks like in practice.

• Movement bounds and speed. The server knows where a player was last tick, the max move speed, and the elapsed time. If the client claims a position that would require moving 30 m in a 50 ms window, the server rejects the move and snaps the player back. This single check kills speed hacks and most teleport exploits.
• Line-of-sight and range on hits. When a client fires, it does not report a kill - it reports "I fired from position P toward direction D at tick T". The server replays that shot against its own authoritative world state (rewinding other players to where they actually were at T, the standard lag-compensation technique) and decides whether it connected. A wallhack that lets a cheater shoot through geometry produces a shot the server's raycast rejects.
• Rate limits and cooldowns. Fire rate, ability cooldowns, item-use frequency, trade frequency. The server enforces them. A client that sends 40 fire events in a second when the weapon caps at 8 gets throttled and flagged, no matter what its local timer says.
• Economy and inventory mutations, server-side and atomic. Every currency change, item grant, craft, and trade is a transaction the server owns. Two players trading the same item must resolve atomically so the item can't be cloned in a race. This is where item duplication exploits live, and they die when the mutation is server-authoritative and transactional rather than a pair of client-side adjustments.
• Sanity checks on every value. Damage within the weapon's possible range. Crafting only with materials the player actually holds. Purchases only the player can afford. Quest completion only when the prerequisites are server-recorded. None of these are exotic - they are the boring invariants a cheat client routinely violates because it never expected the server to look.

The pattern is the same every time: the authoritative component holds the ground truth, recomputes or validates the consequence, and treats the client's optimistic prediction as a hint rather than a fact. For realtime combat and movement, that component is normally the game server. For durable inventory, currency, purchases, progression, and trusted results, it can be a backend service called by that trusted server. Those are related boundaries, but they are not the same process.

Exploits server authority can block (and ones it cannot)

It is worth being specific, because the value is concrete. When the server owns the relevant state and performs the required checks, these client-side claims no longer become authoritative just because the client sent them:

1. Speed hacks - rejected by movement-speed validation.
2. Teleport / flight - rejected by position-delta and collision validation.
3. Item duplication - prevented by atomic, server-side inventory transactions.
4. Currency / resource generation - prevented by server-owned economy mutations.
5. Instant-kill or impossible-damage injection - clamped by server-side damage validation.
6. Inventory injection ("spawn any item") - rejected because only the server grants items.
7. Stat / leaderboard spoofing - the server records the authoritative score; the client cannot submit one.

And the honest part: server authority does not kill everything. Two big classes survive it:

• Aimbots and triggerbots that produce legal but inhuman inputs. The server's hit validation confirms the shot is geometrically possible, because it is - the cheater really did aim there, perfectly, in 4 ms. The action is valid; the suspicious part is the pattern. That is a detection problem, not a validation problem.
• Wallhacks and ESP when the server sends the client information it shouldn't have. If you broadcast every player's position to every client for the client to cull locally, a cheater reads it from memory. The mitigation is server-side culling (fog of war): don't send a client what its player can't see. That is an authority decision about what state to replicate, and it sits in the same backend layer.

Server authority is the foundation, not the whole building. It can reject invalid state transitions, but a legal-looking input can still be automated, perfectly timed, or informed by data the client should never have received.

What client anti-cheat covers - and what it cannot replace

Client anti-cheat products such as Easy Anti-Cheat are designed to make client-side cheating harder and to protect game integrity. That is a different job from deciding authoritative gameplay state. Treat client anti-cheat as one layer in a trust model rather than as a substitute for server validation.

• Client anti-cheat can raise the cost of tampering. It can detect or prevent classes of manipulation on supported client platforms, depending on the product and integration.
• It cannot make an invalid protocol valid. If the server accepts "set my balance to 1,000,000" or trusts client-reported damage, a clean client is not a security boundary.
• A listen-server host is a special threat model. Client anti-cheat may still protect participating machines, but if the host itself is malicious, that host owns the authoritative simulation. Moving competitive authority to a neutral dedicated server addresses a different problem than client tamper detection.
• Platform and privacy tradeoffs vary by product. Do not generalize one anti-cheat's driver model, OS support, or false-positive profile to every client anti-cheat integration. Verify the products and platforms you actually plan to ship.

The takeaway is not "skip client anti-cheat." It is: do not ask client anti-cheat to enforce invariants that belong on the authoritative server or backend.

Server-side detection: telemetry and behavior analytics

After invalid state claims are rejected, some abuse is only distinguishable as a pattern. Server-side telemetry can support that detection, but it is evidence rather than automatic proof: models and thresholds need calibration by game mode, input method, weapon/character, skill bracket, latency, and patch version.

• Aim analytics. Time-to-target, snap angular velocity, flick consistency, target visibility and crosshair-to-target error can be useful features. Compare like with like and avoid treating one global threshold as a ban rule.
• Hit-rate and reaction outliers. Sustained outliers can trigger deeper review or a higher-confidence detector, but skill, matchmaking, input device, latency, weapon balance and sample size all affect the baseline.
• Economic anomalies. Currency or item velocity that outpaces any legitimate play loop flags duping and RMT (real-money-trading) rings even when each individual transaction passed validation.
• Session and account signals. New accounts with veteran mechanics, shared hardware fingerprints across banned accounts, and impossible play schedules are all server-side signals that don't depend on touching the client at all.

This is also where the conversation can move beyond rule-based detection toward calibrated models and review workflows. The important architectural point is provenance: telemetry produced or verified by an authoritative server is more trustworthy than self-reported client outcomes, but no telemetry stream is automatically cheat-proof.

The layered defense model

No single layer is a silver bullet. The defensible posture is defense in depth, where each layer covers the previous one's blind spot. Here is how the layers map to what they actually stop and what they cost you.

Layer	What it stops	Blind spot	Cost / tradeoff
Client anti-cheat	Client tampering/cheat techniques covered by the chosen product	Server-side invariants, malicious authoritative host, valid-looking automated input	Platform, privacy, integration and support constraints vary by product
Authoritative game simulation	Impossible movement, fire-rate/damage claims, invalid hit/state transitions	Legal-looking automated input, information already replicated to the client	Server CPU, networking complexity, prediction/reconciliation work
Trusted backend writes	Fabricated currency, inventory, purchases, progression and trusted results	Realtime simulation cheats before the durable write boundary	Transactions, idempotency, service credentials and recovery design
Behavior detection / analytics	Suspicious patterns, economic anomalies, repeated outliers	Sparse data, distribution shift, confounders and false positives	Data quality, calibration, review and appeal process
Reporting + bans	Whatever the other layers flag for confirmation by humans/players	Slow without evidence from the layers above	Moderation overhead, appeal handling

Read the table top to bottom and the strategy falls out: reduce client tampering where it matters, keep gameplay truth on an authoritative server, keep durable consequences behind trusted backend writes, use calibrated telemetry for suspicious patterns, and keep an enforcement/appeal path for actions that affect real players.

Indie priority order: authority before sophistication

A small team does not need to reproduce a large competitive shooter's anti-cheat organization on day one. Start with the trust boundaries that make the most damaging fabrications impossible: server-owned combat/movement rules where competitive integrity requires them, and server-authorized economy/progression/result writes anywhere value persists across sessions.

Then add the client anti-cheat, telemetry, anomaly detection, reports and sanctions that match your actual abuse. This sequencing is useful because each later layer gets better evidence from the authoritative layers underneath it.

The engineering catch is that realtime authority and durable-state authority are different projects. Netcode handles simulation and reconciliation; the backend handles identity, persistence, transactions and trusted service credentials. A managed backend can reduce the second workload, but it does not replace your authoritative game simulation.

Honest tradeoffs: latency and cost

Server authority is not free, and pretending otherwise is how teams get surprised. Two real costs:

Latency. When the server is authoritative, the client often predicts locally so controls remain responsive and reconciles against server state afterward. Modern netcode frameworks support this pattern, but the implementation still requires careful handling of latency, packet loss, rollback/reconciliation and which actions are safe to predict.

Compute and money. Running authoritative simulation costs CPU and bandwidth, and the bill changes with player count, tick rate, physics/gameplay complexity, replication strategy, region count and redundancy. Validate what must be authoritative and measure the actual server workload; do not choose a tick rate or hosting shape from another genre's architecture.

FAQ

Do I still need client anti-cheat if my server is authoritative?
Maybe. Server authority and client anti-cheat cover different threat surfaces. Competitive games commonly use both; lower-stakes co-op or social games may prioritize authoritative state and abuse controls first. Make the decision from your platforms, stakes, cheat model, vendor capabilities and tolerance for integration/support overhead rather than from a universal rule.

Can server authority stop aimbots?
Not on its own. Automated aim can still produce geometrically legal shots. Detection therefore needs additional evidence such as calibrated behavior signals, client anti-cheat, reports/review, or other game-specific controls. Authoritative telemetry improves the provenance of that evidence; it does not make one statistical threshold a safe ban rule.

My game uses a listen server or player host. Does any of this apply?
Yes, but the threat model changes. The hosting player's machine is also the authoritative simulation, so a malicious host has powers that an ordinary remote client does not. Client anti-cheat can still protect supported participants from some tampering, but it does not turn the player-owned host into a neutral authority. If host cheating is unacceptable, move the sensitive simulation to a dedicated or otherwise trusted server.

Where Crux fits

Crux fits on the durable backend side of this split. It provides player authentication, persistent documents, economy, leaderboards, live config and server credentials so trusted services can keep sensitive writes off an untrusted game client. Competitive score/economy writes should come from your trusted server path.

Crux does not simulate player movement or hit registration, inspect a player's process, replace Easy Anti-Cheat/BattlEye, or ship a turnkey aimbot detector. Your authoritative game server still owns realtime gameplay validation, and any behavior-detection pipeline remains a separate system unless you build one. The value here is narrower and useful: identity and durable consequences can live behind a credential boundary that a modified client does not control.

The point of this whole article in one line: stop trying to win the client-trust arms race, and move the truth to the server. If you want the foundation first, start with what an authoritative game server actually is, then see the full picture in the Crux overview.