• “Validation must be performed server-side. You may (and should also add client-side validation to speed up the user experience and save server round-trips for those users whose browsers support it, but you must always back it up with equivalent server-side validation. It’s trivially easy for hackers to bypass client-side validation, either by faking GETs or even POSTs, bypassing your Hidden and Read-Only fields, stuffing non-listed values into your drop-down menus and radio button lists (all of those can be done with a very common Firefox Extension, for instance), or even by simply turning off JavaScript!” — Much better.

    I agree *if* you are not using parameterized queries, and are using the string concatenation method (very bad idea) as pointed out in the article.  If, however, you are using parameterized queries, intermediate SQL Server server-side validation becomes less of an issue as you don't have to be concerned with SQL commands being injected directly into your queries via parameters, nor with semicolons, apostrophes, or double dashes wreaking havoc in your queries.  Also, if your parameters are defined explicitly to be of the appropriate type and length, truncation and overrun errors from the UI are not an issue that IIS can't resolve.

    Proper DRI, FK relationships, and check constraints on tables will help prevent garbage data from being entered server-side as well.

    Faking GETs and POSTs is beyond the scope of the article, but client-side validation in terms of SQL Server includes IIS validation.  IIS is just another "client" as far as SQL Server is concerned.  When your hidden form field variables, etc., are validated on IIS before IIS submits the query to SQL Server, faking GETs, POSTs, and manipulating form fields is not an issue as far as SQL Server is concerned.  Your reference to client-side JavaScript validation makes me think you are considering the client-server model like this:

                                 ---------------IIS (Server)

    Web Browser (Client) --------|

                                 ---------------SQL Server (Server)

    When in actuality the Web Browser is not directly connecting to the SQL Server.  The actual model is more like this:

    Web Browser (Client) ------- IIS(Server/Client) -------- SQL Server (Server)

    (Of course on SQL 2005, with HTTP Endpoints, this model changes yet again...  But that's for another article).

    BTW - When I type a really long post (like this one), I usually highlight the whole thing (CTRL+A) and copy it to the clipboard (CTRL+C) before submitting to keep it from goinf *poof* when I hit submit.  If it does disappear, I can just paste it right back in and hit submit again