Security Model
Client‑side prediction keeps gameplay responsive, but authority lives on the server. This page explains what data is trusted, how inputs are validated, and patterns to avoid client‑driven exploits.
Trust Model
Server authoritative: Only player inputs are accepted from clients. Game state is never trusted from clients.
Server re‑simulates using received inputs and produces the authoritative state. Clients reconcile to that.
Ownership enforced: The server only accepts inputs for an identity from its owner.
Implications:
A client can’t force state (position, health, spawns) — it can only propose inputs for identities it owns.
Desyncs are corrected by reconciliation; local client changes that don’t match server simulation are discarded visually over time.
Input Validation
Sanitize Inputs: Implement
SanitizeInput(ref INPUT)to clamp, normalize, and drop invalid or out‑of‑range values. This runs on the server before simulation.Extrapolate Input: For remote players, the client may extrapolate locally to smooth visuals. This is not trusted — the server still simulates from received inputs only.
Repeat Input Factor: Cap how many ticks a prior input is reused for remote interpolation; prevents long input stretching.
Checklist:
Clamp analog ranges (e.g., normalize movement vectors).
Gate one‑shot actions (fire/jump) with game‑side cooldowns, not just input booleans.
Ignore inputs that don’t make sense for the current owned state (e.g., jump while already in the air if your design disallows it).
Last updated