Every public web site on the planet is "accepting data from an untrusted remote client" - but allowing public db access is something else entirely.

Not every public web site enforces its business logic in client-side JavaScript and just accepts as valid the data that's submitted to a server. Every game that wants to submit a score to a central scoreboard has this problem, and it's a little absurd to debate the exact protocol by which an insecure-by-design architecture gets exploited.

You can submit the input sequence used along with the high score. You've then transformed the problem for the attacker from simply sending up an artificial score to writing a program to solve the game, which is harder and was an existing vulnerability already.

I thought this was my exact point. I was responding to a comment that replacing the database connection with an API would solve the problem. It wouldn't. Accepting a score from the client is insecure by design.

Every game basically has to trust the scores submitted by users. That doesn't mean it should trust users to mess with other users' scores, and it certainly doesn't mean it should trust users to mess with levels that other users have designed.

Yes, but you can fine grain permissions so a unique client can alter a high score that they previously held, but not alter everyone's scores, which is difficult if not completely impossible in MySQL directly, as well as sanitize data to reject wildly incoherent submissions.

The possibilities of pre-formatting data are endless with an API. Not so much with an INSERT statement.

It is entirely possible to build this kind of API in a SQL server with constraints and stored procedures.

It's also entirely possible to write a webserver in bash.