While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section:
> Encrypt all data at rest in the database
ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something?
I'm not even sure what this is supposed to mean and it is certainly not common practise.
> Use secondary encryption for data identifying users and any sensitive data like access tokens, email addresses or billing details
So two layers of encryption!? Again, how is one supposed to look up an access token or email address if it is encrypted? And it strikes me that if you don't trust the first level of encryption, the solution is to fix that, not add another one.
> Fully prevent SQL injection by only using SQL prepared statements and stored procedures
That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries.
I could go on. The costs of implementing these recommendations would be staggering for the questionable benefits they would provide. It is absolutely possible to have excellent security without implementing any of these ideas, and I don't think they're helpful at all - and certainly not "simple".
> Encrypt all data at rest in the database
ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something?
I'm not even sure what this is supposed to mean and it is certainly not common practise.
> Use secondary encryption for data identifying users and any sensitive data like access tokens, email addresses or billing details
So two layers of encryption!? Again, how is one supposed to look up an access token or email address if it is encrypted? And it strikes me that if you don't trust the first level of encryption, the solution is to fix that, not add another one.
> Fully prevent SQL injection by only using SQL prepared statements and stored procedures
That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries.
I could go on. The costs of implementing these recommendations would be staggering for the questionable benefits they would provide. It is absolutely possible to have excellent security without implementing any of these ideas, and I don't think they're helpful at all - and certainly not "simple".