[TheEskimo]

Sorry, if you read the page linked you'd see that that is not the case. It is open to SELECT, UPDATE, and INSERT. if it were SELECT only that would be read-only.

As it is, that's just stupid as any user can wantonly edit anything. I could trivially edit every level's author to be myself or do intensive operations which result in a DOS.

The only smart way to give clients access to a database is through some sort of frontend entirely under your control which prevents them from having the user/pass and sanitizes the queries.

Edit: Whoops, while I typed this multiple other people did the same. Sorry for the redundancy.

[nicksergeant]

Yes, I replied to my comment and even updated the original comment indicating that I was incorrect.

[soult]

> The only smart way to give clients access to a database is through some sort of frontend entirely under your control which prevents them from having the user/pass and sanitizes the queries.

MySQL maybe, but enterprise DBs (think Oracle, DB2, Postgres) support a very fine-grained access model.

[toyg]

I'd argue that even then, they are less hardened against network-layer exploits than your average webserver. Network security is bread & butter for a webserver, not for your enterprise DB running in safe intranets with only cursory penetration testing.

[soult]

I agree, though if you hardcode username and password into your application there's no need for fancy exploits.