Talk:SQL Injection Prevention Cheat Sheet

1) Anyway, one thing is that VIEWs are not mentioned; I find that it is an important feature that can help enforce the least-privilege principle by providing finer granularity on read accesses. One web-app may need to validate logins, so its associated db user would need access to username and password fields; a different web-app of the same system may need access to the username only; if we're restricted to per-table privileges, that other db user would necessarily get read-access to the password. Cal-linux (talk) 13:45, 9 July 2015 (CDT)
1a) This seems to be somewhat addressed here : https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Least_Privilege but I'll add a few notes on views, or would you care to add this in? jmanico

2) A related mechanism would be that of splitting tables to a fine granularity --- in this example, the username would be in one table, password on a different table --- the login db user is granted read access to both tables (but even then, it would be beneficial to define a view that hides the inner join details of the SQL statement), whereas the other db user gets read access to the table containing the username only.) Cal-linux (talk) 13:45, 9 July 2015 (CDT)
2a) I think this is a bit 2 much detail for a cheat sheet, but go ahead and add it in. It will not hurt any :) jmanico

3) So, I suggest that "Use of stored procedures" be removed as one of the countermeasures --- it could be mentioned in the other countermeasures that they apply to stored procedures as well as to normal SQL statements reading directly from tables or views. Cal-linux (talk) 13:45, 9 July 2015 (CDT)
3a) I agree so I removed it. Check it out now... jmanico