From what I recall of the story, the login for SMB's level database was stored in plaintext in the exe.

That picture is the guy who found it telling the devs, and the devs not understanding why it's a problem.

Cue their database being "hacked" a short while later... and another internet meme is born!

Yep. MySQL credentials in the binary.

Honest question: how could they have avoided that?

One obvious, safe way: set up an API on their servers, abstracting away the need to send actual MySQL calls over the Internet.

While this case is particularly egregious, you are still accepting data from an untrusted remote client.

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.

If one must directly access the database from a client application, the right way is to make sure each user has an unique, secure database credential with only the minimal permissions necessary. However, direct database access is still a terrible idea in most cases, as it is a lot of work to prevent a resource starvation attack.