• I think I'm going to have to disagree with Steve about SQL injection attacks not being T/SQL's fault.

    I mean, T/SQL allows SQL code to have concatenation of statements seperated by a semi-colon, no white space rules *at all*, and a number of other syntactic sins that are simply unforgivable in a modern language.

    So *of course* T/SQL is going to be vulnerable to SQL injection, it's pretty much a given.

    The whole "only use stored procedures and always sanitize parameters" is a direct consequence of T/SQL syntax idiocy. It's a direct violation of separation of code and data.

    If you're expecting data in your parameters there's NO EXCUSE for getting code. None. It all comes back to T/SQL (and SQL in general) mixing of code and data.

    And that's the failing of the language at a design level. It goes beyond principle of least privilege, destroying the possibility of even having the very concept!