Game Server and Backend Security

Use this skill for architecture and owned-source review of consequential game operations. Treat client, listen server, dedicated server, backend, store, and administrative tools as separate authorities. For connection restrictions and ban-duration reports, use network evidence.

When matching repository resources to a network or backend layer, read the server resource guide. It locates the actual README categories and separates protocol, platform service, framework, and token-validation responsibilities.

Map One Consequential Operation

Record the initiating principal, authenticated identity, object owner, requested action, authoritative validator, allowed preconditions, state change, persistence boundary, external dependencies, and observable result. Follow the specific operation through the system before generalizing to all endpoints.

Separate client intent, prediction, authoritative simulation, replicated visibility, and durable account state. Server execution does not establish correct validation, and a player-controlled host has a different trust model from an operator-controlled server. Epic networking overview

Attack Objectives and Failed Boundaries

This is a conceptual threat model. A possibility in the table does not establish an exploitable defect in a particular service.

Authentication Is One Input to Authorization

Distinguish pending, validated, invalid, expired, and revoked session states. An initial ticket/API result may precede the provider's authoritative verification callback. Identity and game ownership are distinct conditions; a particular ticket flow may validate both together. Follow that flow's documented contract. Steamworks authentication and ownership

Independently verify permission for the action, account, target object, title or tenant, and workflow state. Include account linking, support/admin tools, and service credentials in the operation map. Client-side UI restrictions or opaque object identifiers do not replace authorization at the responsible service. OWASP authorization guidance

Economy, Inventory, and Purchase State

Define intended grant, spend, transfer, consume, mint, burn, refund, and administrative adjustment paths before asserting conservation or nonnegative balances. Document transaction boundaries, concurrent changes, partial external failures, reconciliation ownership, and audit evidence.

Distinguish retry deduplication from stale-write rejection. PlayFab Economy v2 documents different contracts for IdempotencyId and ETags, and advises against combining them in the same request because of conflicting retry semantics. Check the chosen API and version instead of recommending one universal pattern. Idempotent transactions, ETags and concurrency

Model purchase UI results, provider verification, eligible ownership, entitlement grant, acknowledgement/consumption, renewal, refund, and revocation separately. Bind verified purchase evidence to its intended game account and durable grant record. For Google Play, a pending purchase does not authorize an entitlement grant; follow documented purchase-state and backend-verification requirements. Google Play billing security

Network Failure Is Part of the State Model

For timing anomalies, replication order, prediction/correction, resimulation or replay evidence, read time, ordering and replay. Determine the observation timeline and ordering scope before asserting an invariant.

Model loss, duplication, reordering, delayed messages, disconnects, reconnects, and uncertain responses. A timeout does not establish that a write failed. Separate repeat delivery of one logical operation from a new operation, a stale write, and a repeated notification; record deduplication scope and lifetime.

UDP supplies neither delivery/ordering guarantees nor communication security. Review application requirements and established transport-security mechanisms; retries still need congestion-aware behavior. Packet irregularity alone is not evidence of malicious intent. RFC 8085

Review Output and Verification

Produce an operation map, authoritative-state inventory, invariant ledger, available evidence, and unresolved questions. Use existing logs, owned-source review, internal fixtures, and documented provider sandbox events for legitimate retries, concurrent updates, pending authentication, and entitlement transitions. Record expected and observed durable effects, including partial failure.

Keep correctness findings separate from cheating attribution. Use research-rigor for evidence strength, game-engine for replication details, and game-supply-chain-security for deployment authority.

Primary sources reviewed: 2026-09-09. Provider examples are version-specific contracts, not universal guarantees for every backend.

Data Source

Use the following repository sources directly when applying this skill. Prefer available local files for discovery and scoped historical inspection; use the raw URLs when the collection is not installed locally. These entrypoint details are retained here so source lookup does not depend on loading another skill.

0. Compiled Wiki

Start with wiki/index.md for topical synthesis and cross-project connections. Wiki schema describes its structure. Generated wiki pages are discovery aids; follow their original citations before adopting technical claims.

Raw catalog: wiki/index.md. This skill does not currently have a matching wiki overview. Use its local references and the wiki catalog to find related pages; do not invent a path.

A direct project question can start with its README entry or description below; reading the entire wiki is unnecessary.

1. Project Overview and Resource Index

README.md contains the collection's actual categories, subcategories, project URLs and short descriptions. Find the relevant category and retain the original URL, including any specific file or revision suffix.

Raw index: README.md.

2. Repository Descriptions

For a concise project summary, look for the actual local path:

description/{owner}/{repo}/description_en.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/{owner}/{repo}/description_en.txt

Example: bgfx description. Extract owner/repository from the original GitHub project URL, omitting a .git suffix. Resolve existing path casing before constructing a local/raw path. Descriptions are generated summaries, not independent verification. If absent or inaccessible, use the README entry, relevant archive or original project.

3. Repository Source Archives

For deeper inspection of an available captured source tree, locate:

archive/{owner}/{repo}.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/{owner}/{repo}.txt

Example: bgfx archive. Prefer inspecting the relevant portion of an existing archive over re-cloning merely to inspect the same captured material. Archives may exclude files, use fallback extraction or contain truncation; they are not guaranteed complete checkouts. Record any upstream revision evidence and included-file limits. If missing or insufficient, follow the README's original upstream URL.

Choose and Verify the Source

For a specific project, locate its README identity, use a description or wiki page for orientation when helpful, then inspect the relevant archive/source artifact for the question. For current compatibility or exact implementation, verify the matching upstream documentation, release or immutable source revision. Keep the collection revision and capture/generation dates separate from the upstream version. Multiple generated layers from one source are not independent corroboration, and missing archive content does not establish upstream absence.

The per-domain resource guide above helps choose useful artifacts. Shared repository navigation adds the optional read-only indexer, case-ambiguity handling and maintenance details; it supplements this Data Source section rather than replacing it.