10,000 points in 1 second: game API security audit

Executive Summary

During a black-box assessment we identified 5 vulnerabilities, including 2 critical ones. The core issue: the server trusted client-side data too much, allowing manipulation of game logic.

Points fraud and leaderboard takeover (game economy compromise).
Monetization bypass (lives / game state).
Risk of GPS track and PII leakage via Admin API if admin access is compromised.

Context

Scope: Game API and Admin API.
Method: black-box (no source code), testing business logic, user state, and data privacy.
Verdict: production launch is not recommended until critical V01/V02 are fixed.

Vulnerabilities (summary)

V01 — points-awarding business logic bypass (CRITICAL)

The POST /v1/scores endpoint calculated points based on area and timeTaken, but did not validate the physical plausibility of the route. With an empty pathPoints, route validation was effectively disabled.

Impact

Any user could manually send a request with abnormal values and receive points that were persisted server-side (201 Created). This enables leaderboard fraud and direct damage to the economy/rewards.

PoC (anonymized)

Example of an abnormal request (simplified):

{
  "area": 1000000,
  "timeTaken": 600,
  "timestamp": "2026-04-07T19:00:00Z",
  "pathPoints": []
}

The server responded 201 Created and returned awarded points while persisting the result.

V02 — mass assignment / player state manipulation (HIGH)

The PATCH /v1/me/game-state endpoint allowed direct overwriting of internal player properties. For example, setting lives increased the number of lives without server-side validation, which breaks monetization.

V03 — risk of GPS track and PII leakage via Admin API (MEDIUM/HIGH)

Admin API responses contained “raw” route coordinates and personal data. RBAC worked for normal users, but if admin access is compromised, the risk of de-anonymization and tracking becomes significant.

V04 — JWT security: HS256 + no immediate revocation (MEDIUM)

Tokens were signed with HS256 (symmetric key), and logout did not invalidate the token immediately: repeated requests with the same token could still work. The window was limited by a 15-minute TTL, but compromise risk remains if the secret leaks.

V05 — public Swagger UI (/docs) (LOW)

Documentation simplifies reconnaissance and speeds up discovery of attack vectors. Not a vulnerability by itself, but it increases the attack surface.

What was done right

Strict schema validation (e.g., blocking undocumented fields).
Resilience to some injections/anomalies (negative/zero values were rejected).
Basic BOLA protection in key flows tied to token identity.

Fix recommendations

Anti-cheat for V01: require routes, compute average speed server-side, add physical limits (e.g., speed > 20 km/h → reject), and log suspicious attempts.
Field filtering for V02: allow only safe UI settings in PATCH; lives/points/status must change only via server-side triggers after validation.
Privacy for V03: return aggregates instead of “raw” tracks; mask start/finish points; enable access to coordinates only when necessary and via a controlled process.
JWT for V04: move to RS256/asymmetric keys + revocation mechanism, or a server-side session reference depending on architecture.
/docs for V05: Basic Auth / IP allowlist / disable in non-prod to reduce attack surface.

Need an audit or an API review?

Message me on Telegram — I’ll clarify the context and suggest how to quickly find the most expensive vulnerabilities in business logic and access control.

Message on Telegram