I suppose so, but this heavily relies on no one in your operation having made a mistake, or that mistake having been caught before it was pushed live.

You have to be lucky every time, an attacker only needs to be lucky once.

Above you are essentially saying every application has SQL injection vulnerabilities and any good security guy will find them. This is a very specific and dubious conclusion to draw from the more general principle that there will be some vulnerability, somewhere. SQL injection specifically is quite easy to avoid. With some frameworks it would actually be rather laborious to introduce an SQL injection vulnerability. This is what Alexander is alluding to. This does not imply that applications are easily secured, just that this attack vector isn't what it used to be.

Well, statistics of pentests does show that, if tested, the vast majority of good quality, generally securely built applications have some vulnerabilities, and average applications have a huge multitude of vulnerabilities.

SQL injections are just one class of many. There are ways to vastly reduce SQL injection risks but that still leaves many other venues of attack.

No, I never have to be lucky at all. I literally can not put an SQL injection vulnerability into production unless I do so deliberately, my code wouldn't compile. Not everyone uses terrible rails style "lets automagically do shit behind your back so security holes are hidden from you" frameworks.

You're being too harsh. You seem to be talking about Haskell, so saying "not everyone" is a weird way to put it. You really mean a tiny fraction of people use Haskell to be safe in advanced ways. Well, Haskell is ahead of its time. Of course not that many people use it.

Even Haskell is not a silver bullet against every kind of security problem. Didn't Snap have a directory traversal bug a while back?

I don't understand what you are trying to convey. It appears like a deliberate red herring to try to distract from what I actually said. I personally use haskell, but you do not need to do so to get a complete guarantee against SQL injection. Nobody said anything about silver bullets or protecting against every security problem. I very clearly said SQL injection is a solved problem, in reply to someone claiming every single web app has SQL injection vulnerabilities in it and that any security researcher can easily sit down and exploit them, and the only way to deal with SQL injection is to be lucky over and over.

You are being too harsh (again). Whatever problems you deal with, whatever mistakes you make in your professional work, are also solved problems, using some technology that is unacceptable to you (probably for very good reasons).

You could have been informative and made your original point tactfully. Instead, you badmouthed a certain technology without even naming the stuff that was supposedly better. I'm a Haskell evangelist and agree with you 100%, and you came off like a jerk even to me.

I think perhaps we are operating with very different definitions of harsh. If your response is simply intended to be a poor attempt at criticizing my tone, you did not make that clear. Obviously such vacuous nonsense would not warrant a response.

Your assertion that whatever problems I deal with are solved problems is absolutely insane. Please, tell me how problems like interpreting customers requirements are "solved" and what technology I can use to ensure that all the code I write will 100% always match the users mental picture of what they wanted.

Criticizing the choice to deliberately create security holes for convenience is not "badmouthing", and "I'm offended" is not a productive response. It literally conveys no useful information at all.