Please excuse me if this comes across as anything other than constructive criticism, but I don't believe checklists should be used to guide web developers to bu

Please excuse me if this comes across as anything other than constructive criticism, but I don't believe checklists should be used to guide web developers to build secure software. My reason for this belief is that, in my experience, it engenders tunnel vision and what I appropriately refer to as a "checklist mentality". There are developers who believe, "We're immune to the items on the OWASP Top 10, so we're secure," when there are entire classes of vulnerabilities that applications can be vulnerable to (say: using a weak and predictable PRNG for their password reset tokens) that isn't adequately described by the OWASP Top 10. An alternative approach that I feel is more helpful is to organize insecurity into a taxonomy. * Code/data confusion * SQL Injection * Local/Remote File Inclusion * Cross-Site Scripting (XSS) * LDAP Injection * XPath Injection * Several memory corruption vulnerabilities * Logic Errors * Confused deputies * CSRF * Failure to enforce access controls * Operating Environment * Using software with known vulnerabilities * Using HTTP instead of HTTPS * Cryptography flaws * Yes, this deserves a category of its own * Chosen-plaintext attacks * Chosen-ciphertext attacks * Side-channel cryptanalysis * Hash collision vulnerabilities (e.g. length-extension) * Weak/predictable random values You can further break down into more specific instances. There are three types of XSS (stored, reflective, DOM-based). There are blind SQL injection techniques worth studying too. But the underlying problem that makes these vulnerabilities possible is simple: User-provided data is being treated as code. Any technology that prevents this confusion will greatly improve security. For example: SQL injection is neutered by using prepared statements. You might one day forget to manually escape a single input (and it only takes one to be game over), but if user data is always passed separately from the query string (i.e. you never concatenate), there's no opportunity to make this mistake. There were also corner-case escaping bypass attacks (usually involving Unicode) that you might not be vulnerable to. With prepared statements, these clever multibyte character tricks accomplish nothing. The query string is already in the database server before your user's parameters are sent. I believe teaching developers to think in terms of taxonomy (very general to very specific) will result in a greater understanding of software security and reduce the incidence of vulnerable code. I've written about this before, in case anyone wants to link to something besides an HN comment: https://paragonie.com/blog/2015/08/gentle-introduction-application-security https://paragonie.com/blog/2015/08/gentle-introduction-appli... --- EDIT: Opened an issue: https://github.com/FallibleInc/security-guide-for-developers/issues/14 https://github.com/FallibleInc/security-guide-for-developers...