The socket.io library itself may have bugs, and if you use it, you may inherit those bugs.
Then again, the TCP implementation in your kernel may have bugs, and if you use it, you may inherit those bugs.
socket.io is more commonly used than any random networking library, so it's likely to be better-debugged than any random network library (and probably better-debugged than your own.)
Developing with socket.io isn't really that different from developing with regular web protocols, or with straight sockets.
The most important thing to pay attention to is making sure that you don't just trust the data from the client. If the client is in a pre-login state (hasn't yet had name/password validated,) then don't accept any gameplay requests. Remember which client was authenticated for a particular socket, and don't accept requests trying to claim they're another player. Don't do fancy things like passing functions or text to eval() over the protocol -- this leads to security problems for sure. Stick to basic data; numbers and strings and bools and nulls, and objects/arrays that contain only those things.
When time comes to mutate the database, don't expose a protocol that says "read database X" or "write database Y." Instead, expose functions that are specific to your game, like "get the list of gem inventory items for my character" or "consume 3 cords of wood to make a pile of charcoal." Don't try to be "smart" and pass in things like names-of-fields or names-of-tables in the protocol, so the user can substitute their own names. The dumber, the better. Use prepared queries and parametric arguments for your database access: Use ("update foo set bar=:value", {value:argument}) instead of "update foo set bar="+argument.
Finally, as frob said, when a user registers, and you receive email and password, call scrypt() or bcrypt() on the password, and store the output of that function in your database. Require passwords to be at least 12 characters long, and accept up to 255 character long paswords. Require that the password is not a subset of the email address, or vice versa. Don't have other password rules, except possibly "requires at least one space and at least one non-space character." Make sure the registration page runs over HTTPS. When the user tries to log in later, verify the password they provide you using the scrypt/bcrypt verify() functions.