I've had an anonymous comment on this Blog piece (and, remember, our Blog is for starting discussions, not reporting revealed truth), via email:

"This article has one gapping hole. The Developer can not do much when the Documentation of the API's is so so unbelievably poor, or non existant."

Fair comment - and perhaps an argument for Open Source, where the developer can look at what's behind the API (although having to do so probably won't help you to write secure code to a tight deadline).

I remember thinking that when Microsoft was accused of maintaining "secret" or undocumented APIs for its own coders some years ago, that this was possibly more to do with its embarrassment over poor practice that had escaped into production product than machievellian malice, But, poorly designed or documented APIs certainly don't help you to write secure code.

Hopefully, as a new convert to security good practice, Microsoft is now writing better APIs. However, I do see the existance of poor APIs as an opportunity for automated code analysis and "security testing" tools. Given a poor API, coders will tend to make similar mistakes when using it and, surely, a tool can look for the expected symptoms of this and highlight the potential issues?

Not as good as designing in security from the first and working with simple, well-documented, well-structured APIs, of course. However, surely it's a reasonable way of making the best of a bad job? And may embarrass vendors into addressing any unerlying issues.

After all, even if you (as a developer) have to use less than perfect tools, you probably still can't just wash your hands of security, not if you want to continue getting paid, anyway.