Jammer. Als je succes hebt, zullen er altijd mensen/groepen zijn die je dat succes niet gunnen en op alle mogelijke manieren zullen tegenwerken. Anderzijds wordt je op de proef gesteld en krijg je de gelegenheid om orde op zaken te stellen.

Het enkele feit dat er SQL-injectie mogelijk is, is natuurlijk ernstig, maar hoeft geen onoverkomelijk veiligheidsrisico te zijn, mits de database-gebruiker alleen leesrechten heeft. Omdat je (natuurlijk!) geen gevoelige data plaintext in de database opslaat, is zo ongeveer het ernstigste wat er kan gebeuren dat e-mailadressen van gebruikers bekend raken. Dat als zodanig is een privacy-issue (en dus ongewenst!), maar zal niet leiden tot ernstige gevolgen voor de gebruiker (het ergste wat er kan gebeuren is dat de gebruikers extra spam ontvangen).

Zelf hanteer ik bij het gebruik van databases voor webapplicaties minimaal 4 gebruikers,
(1) één met alleen-lezen toegang gebruikt wordt voor alle SELECT queries;
(2) één met schrijf-bevoegdheden in de relevante tabellen voor de front-end;
(3) één met schrijf-toegang voor de relevante tabellen voor de backend;
(4) en de laatste voor de het lezen en schrijven (maar niet updaten en deleten) van de log- en audittabellen.

Naast alle pogingen in de code die gedaan wordt om sql-injectie te voorkomen (alleen gebruiken van parameterized queries, input checking op geldige waarden in plaats van het filteren op ongeldige waarden) minimaliseer je zo de impact die een aanval kan hebben mocht het onwaarschijnlijke toch gebeuren.

Als je vandaag de dag nog een website/webwinkel hebt die gevoelig is voor sql-injectie, sterker nog, de hele database is uit te lezen.... F*ck*n shame on you!!! Incompetente sukkels het zijn ' OR 1 = 1.

De meeste beheerders weten echt niet wat een SQL-injectie is, doet of hoe je 't kan voorkomen.
Functionality gaat gewoon boven security... Simpel zat.