1 - So, what you mean with 'webserver that does the database transactions' did you mean, like a real computer with a fixed IP waiting and receiving data from the clients and doing the transacitons?
OR
2 - you meant like a PHP webpage that receives the client´s incoming request of information and then make the transaction?
Whatever you want, although its probably easier to achieve in PHP.
Thanks in advance in case if you post/awnser something that could help or enlight my narrow knowledge of 'webserver security' instead of negative criticism that would want make me shut my project down.
If I can stop you from doing stupid things, I'm okay if it comes to the price that you stop your project
Webserver security is a huge topic, you have to deal with many things like authentication, authorization, malicious users and so on. The key is probably to trust no one, not even what looks like your game since virutally anyone out there can pretend to be your game. Always run sanity checks on the input that you take from 'the wire' and if you are using certificates for authentication and authorization, always check the whole certificate and the signing authorities. You should also check the revocation information, just in case someone was able to get a root CA to sign malicious certificates (like what happened to diginotar for example).
Although, if there is nothing crucial going over the wire, like passwords or other sensitive user data, you don't really need to encrypt everything. For issuing quests to your users its perfectly fine to use no authentication and encryption whatsover but just having the client connect to your webserver that in return queries the database and returns the result to the client.
In a REST environment this could look like this:
Client calls: mydomain.com/mygame/quests/
Server does: SELECT whatever FROM quests WHERE somecondition
Server sends all returned rows from the database
Client runs some sanity check on the response and then adds all new quests.
