How does Nakama protect against SQL Injection?

Does Nakama have any sort of protection against SQL injection?
I’m concerned about server security, and I would like to know more about the possibility of user-submitted data like display name editing and password change being able to compromise the database.

I’m assuming some stuff, because I didn’t take that close of a look at the source code, but:

Nakama most likely handles their sql queries by using stored procedures, which provide the most optimal security against sql injections.

If you are using the low level sql api’s to run your own queries you yourself are responsible for the security (and performance!). Therefore it’s not recommended unless absolutely neccessary.

1 Like

All Nakama APIs that ultimately make SQL calls to the database use the server’s own built-in queries. Queries are never accepted from clients.

Additionally all parameters these queries require (whether they come from Nakama or the client) are passed through as parameters, not mashed into the query string. Even if a user tried to for example use a SQL fragment as their username, they’d only ever end up with a funny-looking username - assuming it’s even a valid username based on Nakama’s rules, but this is just an example. The SQL fragment would never execute.

Alongside our own testing Nakama is currently used in a significant number of large projects. As you can imagine each of these developers, teams, and studios have tested and vetted the server using anything from code inspection, automated fuzz testing tools, static code analysis, and more.

That said code and queries you may write yourself using the runtime is your responsibility, but Nakama provides all the tools you need to apply best practices such as separating queries and parameters.

1 Like