[jrockway]

It doesn't really matter that it's contrived. It's hard to show the value of something in a large system, because 90% of the blog post will be understanding that large system. So you have to pick something that is immediately obviously wrong, and let the reader make the jump to how this would actually be useful in the context of their own larger system.

Even then, the approach of "just do it right the first time" is fallible. People have varying degrees of experience, and people have brain farts and type the wrong thing instead of the write thing. Your job as the technical lead is to have some sort of process in place to catch these things before they become security disasters. "Sorry, our junior engineer didn't know about prepared statements," is not something you want to tell your customers whose data was exfiltrated. The current industry standard here would be "cross your fingers and hope for the best", and that's why everyone knows your social security number and have opened 6 credit cards in your name. Fuzzing is another layer of sanity checking, on top of static analysis (where I think this issue should be caught), code reviews, and just typing in the correct code in the first place.

At the end of the day, this just another example of how you could use fuzzing to detect problems that other things missed. That's valuable, as even with 100% code coverage and turning on all the lint checks, software still has bugs. Here's a tool that can help reduce the bug count.