Security for HTML5 games

With SmartFoxServer 2X 2.13.4 we introduced websocket origin checks for HTML5 clients. What this mechanism does is essentially verify the provenance of the client against a white-list of domains configured by the server admin. If the client origin does not match any of the allowed domains the client connection is denied.

In this article we’ll demonstrate how to use and configure websocket origins in SmartFoxServer 2X and discuss the advantages and limitations of this security measure. We’ll also take a deeper look at the issue of cheating clients and propose several ideas to improve the security of your online game.

» Who is knocking at the door?

Publishing a multiplayer HTML5 game online has many advantages, one of which is that the game client itself is always available for access to any player armed with an Internet browser.

This direct availability however can also attract folks who are not interested in the game itself but rather in messing with it, by dissecting the client and trying to understand how to take advantage of potential flaws or bugs.

With web-based games cheaters can have an easy time accessing the game client’s code and try to recreate a different client that attempts to abuse the system. Without a specific protection that is able to recognize a genuine client from a fake one, it will be very hard to get rid of these attackers.

» Websocket origin to the rescue

Fortunately for us the websocket protocol includes an “Origin” parameter in the HTTP request (specifically in the “upgrade” request) that can be leveraged to apply some basic security checks.

In fact the “Origin” value will tell us the source of the web page requesting a socket connection and with that we can verify it against a list of safe domains.

Below is a screenshot from the SFS2X AdminTool, under the Server Settings > Web server tab

Here in the “Allowed client origin” box we have configured two valid domains:

  • this specifies that only clients from this domain can connect to SFS2X, without exceptions. For instance will be rejected as it doesn’t strictly match our setting.
  • * using a wildcard (asterisk) allows to loosen up the check a bit. In particular this allows any third level subdomain of, such as or, to be able to connect.

By default SFS2X is configured with no allowed origin configured. In this case any client will be allowed to connect via websocket.

When origins are specified the server will match the client’s provenance with the white-list and shut down any connection attempt that fails the check. If someone steals your game code and then attempts to run a modded version from his computer or another online server, he will be out of luck as no connections will go through.

NOTE: keep in mind that only one wildcard is allowed per entry and it must be placed at the start of the domain entry. Examples such as these:

  • *.*.my.domain-com
  • subdomain.*

are incorrect and will be rejected.

» Limitations and improvements

While the origin check is a good security measure to keep activated it won’t protect you from other cheating attempts. In particular, smarter hackers could be able to forge an HTTP header and fake the origin to what the server expects, even if the client is effectively coming from somewhere else.

For instance, this could be done by building a client in Java or C# using a websocket library to send the fake origin, thus bypassing the protection. From there the cheating client can communicate with the server and none is the wiser.

There are supplementary techniques that can be employed to increase the origin protection. For example, by generating a unique token in the game’s starting HTML page so that it can be sent back to the server at login time for validation.

The system essentially allows for a two-step validation, the first at connection time and the second at login time.

Even this countermeasure isn’t 100% hack-proof since setting a token on client side still provides opportunities for malicious clients to scan the HTML for such token and then using it in a custom built client.

» Higher and lower level security measures

Verifying the client’s origin and introducing a dynamic token to be verified at login time are valid ways to keep a number of attacks away and discourage casual hacking attempts.

The better protections, however, usually comes from proper validation of every incoming request. In particular it is crucial to run most of the game logic on the server side and remove any authority from the client. This way even if attackers can bypass the client origin checks, no real harm will be done since the server will deny any of their potential shenanigans.

There is an old mantra in multiplayer development that says: “the client can’t be trusted“, which is probably one of the best principle upon which building any multiplayer game.

» Learn more

If you’re interested in learning more about securing your multiplayer game we highly recommend reading this in-depth security white-paper.

The document analyzes many aspects of online game’s security, the relative tools that SmartFoxServer offers and the best practices to avoid common attacks and secure the game.

For any feedback or questions you can always reach us via our support forums.