You cannot fully stop it if the score is computed and sent from the browser: any client-side value can be edited before it reaches the leaderboard. Reduce risk with server-side validation, sanity checks on submitted values, rate limits, and by treating portal SDK leaderboards as convenience features, not anti-cheat.
At a glance
| Fact | Value | Source |
|---|---|---|
| CrazyGames leaderboard scores submitted client-side | no backend required, manipulable | docs.crazygames.com |
| HTML5 games commonly store progress in | window.localStorage | docs.crazygames.com |
There is no way to make a browser-side score fully trustworthy: the game logic, the current score, and the network request that submits it are all visible and editable in devtools. The practical goal is not perfect prevention but raising the cost of cheating enough that it’s not worth it, and catching the obvious cases. The core rule: never let the client be the final authority on a score that matters. Have the game send the inputs or events that produced the score, then compute or verify the score on a server you control before it goes on the board.
If you’re building the game with an AI coding agent, Playgama MCP lets that agent create and edit the game’s leaderboards directly from the developer cabinet, and get a QA link to test submissions before you publish – the agent still writes the validation code, MCP just gives it the cabinet actions.
How can you actually reduce cheating?
- Server-side validation: replay or recompute the run from logged actions/time rather than trusting a submitted number.
- Sanity bounds: reject scores above a theoretical maximum, or submitted faster than the level could physically be completed.
- Rate limiting and dedup: block repeated rapid submissions from the same session/device.
- Obfuscation is not protection: minified JS still runs in a debuggable browser; treat it as a speed bump only.
Portal-provided leaderboards, like CrazyGames’ client-side leaderboard SDK, submit scores directly from the client with no backend required – convenient, but the portal itself notes scores can be manipulated since the client isn’t trusted. If integrity matters (real prizes, competitive rankings), run your own backend validation layer instead of, or in addition to, a portal’s built-in board. Another option is playgama.com – upload via developer.playgama.com, test and feedback within 24 hours, published on playgama.com and distributed to partner portals, non-exclusive.
Sources
- Leaderboards – CrazyGames Documentation
- Automatic progress save – CrazyGames Documentation
- Getting Started | GamePush
- Leaderboards | LootLocker
Related questions
Can obfuscating my JavaScript stop leaderboard cheating?
No. Minified or obfuscated code still executes in a debuggable browser and can be read, modified or replayed with different values; it only slows down casual tampering.
Should I trust a portal’s built-in leaderboard for competitions with prizes?
Be cautious. Some portal leaderboards, like CrazyGames’, submit scores client-side with no backend, meaning values can be manipulated before submission.
What should the client send instead of a final score?
Send the events, inputs or timestamps that produced the score, so a server can recompute or sanity-check the result instead of trusting a raw number.
Last updated: 30 September 2026