Let's talk about computer security! Now, I know the last thread about it got a little heated, so let me preface this by saying that I'm not accusing you of doing anything wrong. In fact I really appreciate you acting on the advice you've received back then! I just have some more advice that should hopefully help you improve further if you choose to. Some of that might be overkill for such a small project, but the knowledge might still prove useful for future ones.
It's trivially easy to make a system completely unhackable - just don't connect it to the internet, and all hostile actions against it will be impossible.
The difficult part of security is to
allow some actions, while
not allowing others. Or in your case, allow users to submit their scores and view those of others, but don't allow them to vandalise the database and delete other people's scores.
The initial version of your database plugin had the rather notable security flaw of listing the database login and password as plugin parameters, allowing anyone to read them from plugins.js. This was not ideal, as the set of allowed actions for each user basically included
all of them, including deleting the database completely.
I see that you've since improved the way you're handling high-scores, by having a separate server that connects to the database directly, and having the game simply instructing the server what to do.
There are, however, still considerably more allowed actions than there should be. Anyone can simply type
https://www.trimitysolutions.com/databaseba.php?action=select_descending&table=ranking&column=boss_count into their browser to get the list of all scores directly. That's not really a problem, since it's meant to be public anyway, but they can also use the
insert and
delete_where actions just as easily (I won't list the exact commands here for obvious reasons, but they're no harder to figure out). Which not only allows anyone to not only insert arbitrary scores into the list, but also remove everyone else's scores.
While you've delegated some responsibilities away to the remote server (that players can't control), you haven't delegated enough. There's no reason for the players to be able to request deletion of data, for example.
So, how do we improve this?
By delegating more responsibilities to the server.
Instead of telling the server directly to perform a given action on the database, simply tell it what happened in the game. Have an action that tells the server which player defeated how many bosses, and get the server to update the database accordingly. And of course another action for registering a new user. And presto, nobody can just delete all records now!
They can still increase the scores of other players though, since we don't check if they're increasing their own. So an attacker could just add random amounts of kills to everyone, which is an effect that's not far from deleting all data.
A solution for that would be use secret user ids that we never show to the client - working a bit like a password. For each player, generate a long random string when they make an account.
Each client remembers their own secret id, and sends it when they want to report increasing their boss count. The server checks if it matches, and only changes the score if it does. And when providing information about other players' score, it only returns the
username and
boss_count columns, not the secret ids. And presto, now we can only modify our own scores!
Now, while a player can only modify their own score, they can still make it whatever they want. Fixing that would be... rather challenging. In a professional game, the client would probably send a list of actions they took in combat, with the server verifying if they should have resulted in the same outcome the client claims they did.
For reasonably simple fixes, there really aren't any. You can make cheating harder - for example encrypting your game's code, or submitting the total amount of damage dealt in last fight (which the server would verify whether it matches the boss). But a determined enough cheater would still be able to get around that, just using more time.
Though one rather simple fix is to reject all values higher than the number of bosses, so at least you won't end up with impossible scores on the leaderboard.
There's also another problem - people can still create as many new accounts as they want, and setting a score for each one. You could have the server reject account creation for IPs of existing accounts, but that wouldn't stop everyone, and might annoy regular users who share an IP address.
A better solution is to use a third-party service to handle account creation - they usually have plenty of anti-spamming measures against creating accounts en masse. Though that wouldn't let you have such a seamless account creation process, so it's definitely a trade-off.
And another thing: while I don't know how exactly your server works - make sure are using prepared statements, or otherwise sanitising the data that comes from the client. We don't want to run into a
Bobby Tables situation.
Well, I hope you found some of this useful, or at least interesting. I don't think you
have to implement any of these changes - it's your project after all - but if you don't want everyone to be able to delete all records, I definitely recommend implementing some.
PS. In case you're wondering how tempted was I to insert a user with 15001900 boss kills - quite a lot. I managed to resist it though
:p