MattF wrote:I believe you'll find that statement is incorrect, if I remember correctly. Prepared statements are, (from memory), an extra layer of protection but not a foolproof one.
Only if you use them the same way you would use regular queries, which of course completely defeats their purpose and all their advantages.
pepak wrote:I agree generally, but I do think that there are cases where rigorous validation isn't worth it. E-mail-like logins for various IM services are one such case.
Rigourous validation and sanitisation is *always* worth it. Any other approach is, inevitably, at some point in time, just putting up a big sign asking for problems.
I would appreciate if you kept to the arguments at hand. We were talking about validation. Now you add sanitization, which is a whole different matter: sanitization cleans data from possible malicious parts (and obviously needs to be done every time), validation only makes sure that it is formatted in a certain way (and experience shows that you will almost always find valid inputs which are formatted differently than you expected).
If you wish to take the haphazard approach personally, then by all means do so. A project such as this should have no coding practices such as those inplace, however. Security is paramount.
Is it? Really? There are great many avenues to improve security, but it could be argued that many of them increase it only marginally while increasing costs a lot. Or that some of these approaches would add more security and should be done first - e.g. those prepared queries, or different database account for administrators (EVERY database should have at least three users - owner, who can not login from the web server, admin, who can modify everything but can't e.g. drop tables or databases, and user, who can only read and write what's necessary for him to read). Input validation is nice to have, certainly, but its importance is relatively low if rigorous sanitization is done on output.