Security issues with the GM backend

• It is difficult to authenticate communication between a server and a HTML5 application
• Communicating with a server other than the application's host will trigger CORS cross-site restrictions
• Communicating with a database typically requires a further username and password, typically embedded in the script
• Shared CGI servers may allow other account holders to access your files 

It is difficult to authenticate communication between a server and a HTML5 application

This follows from the fact that the application is ultimately a script running on a machine that is outside your control. It is hard to ensure that an HTTP action really did originate from the application and not a modified copy or a manual HTTP tool. Embedding a "key" helps but is still only "security through obscurity".

Communicating with a server other than the application's host will trigger CORS cross-site restrictions

This limitation unreliably blocks communication between your application and a CGI server if the server has a different hostname than the application's server.

Currently I know of three solutions:

1. Host the application using the same server that hosts the CGI script. The limitation applies to hostnames not folders so it should be entirely possible to put the application in "public" and the script in "cgi-bin"
2. Configure the CGI script to output the CORS Access-Control-Allow-Origin header with a value of "*" meaning "allow all"    
3. Output the Access-Control-Allow-Origin header with the appropriate hostname noting that this may require negotiation between the host and browser

At this time I am advocating option 2, but on the assumption that impersonation will at most allow an attacker to deface a high score table, and possibly disrupt saved games.

Communicating with a database typically requires a further username and password, embedded in the script

This just seems like a frustrating weakness of CGI scripting, though it is hard to see how it could be fixed. If the username and password are stored in a configuration file then the file may need to be marked as executable to prevent it being inadvertently shared via HTTP. In the absence of a dedicated process authentication service the best we can do is to hide the database access details. Security through obscurity again.

Shared CGI servers may allow other account holders to access your files

This problem is diminishing as it is increasingly likely that a hosting account will feature a dedicated virtual machine, but under the older model all user accounts were stored as usernames under one operating system, and the shared web server had its own username. As the web server needed to access files to serve them the system needed group-read permissions as a minimum and this could be abused.

Security Precautions

1. Start from the assumption that the system will get hacked somehow and try to limit the damage
2. Accept that injecting bogus values as script parameters is an easy attack, remember to sanitize input values
3. Assume that a system that is hacked at filesystem level will have had backdoors installed, and that all scripts must be deleted and reloaded
4. Avoid invoking a command shell unless you are absolutely certain the parameters are sanitized
5. Be very careful with the PERL string find and replace operators, in particular take care with using variables in the search string as this may allow a shell command to be executed through "backticks" functionality
6. Think twice about using a database if a simple text or binary file will do the job