 the authorization and authentication must be done on the DB side, which is a rather clean design, and hardly a WTF. In such case letting anyone execute just any queries is not dangerous, and even if it results in users executing (sometimes) slow, unoptimized queries, it is something you can't prevent on any system that has a thick client. And that's it.  Careful attention to detail, though -- look how all those quotes line up in a row on the right side. After the database is destroyed, at least this neat formatting will be left.  Unless, of course, the attacker uses SQL injection to delete the site files too. Bwahaahaaha!  SQL Injection? Why bother, when you have actual PHP Injection. Who said the PHP code you send to the server has to do any SQL at all? Have it exec a shell on a TCP port, and voila, you've got shell access as whatever user the webserver is running as.  Well, whatever the method of destroying the site, this design does have the advantage that the whole source code for the application might actually be in the browser cache, and I guess you could use the browser itself to put it all back. Self-repair.  All they need is some code in the javascript to the effect  "if (site has been obliterated) evalPHP( code to reconstruct the whole site )"  The next visitor who has the pages in cache would, albeit slowly, put the whole site back in place. It's like a massive and unintentional cluster.  Well, whatever the method of destroying the site, this design does have the advantage that the whole source code for the application might actually be in the browser cache, and I guess you could use the browser itself to put it all back. Self-repair.  All they need is some code in the javascript to the effect  "if (site has been obliterated) evalPHP( code to reconstruct the whole site )"  The next visitor who has the pages in cache would, albeit slowly, put the whole site back in place. It's like a massive and unintentional cluster.  