Writing Secure Code

Security is the paramount issue when deploying a product over the internet. Here I am trying to collect a set of principles for writing secure code, that I have collected from different places on the internet.

1. Any functionality you have built can be used by anybody with an ulterior motive. Design functionality/endpoint/service/microservice with a mindset that guards against the most rogue user of that functionality.
2. All user input coming your way should be assumed to be coming from a most rogue user of the functionality. Follow the steps defined below. 
1. Sanitize
2. Validate
3. Execute
4. Display feedback
3. If you have defined endpoints and provided a web client or an app, Don't assume that is the only method that will be used to access your endpoints.
4. API Keys are as important, if not more important, than usernames and password. Guard them like that.
5. Any place you are using API keys or passwords, think, what will you do in case these are exposed. How will you handle key rotation? Particularly if you have a device as your client, it should be capable of handling key rotations, or forced password change.
6. Passwords and API keys should not be part of the code and committed to configuration management systems.
7. If you are using encryption with keys (e.g. AES 256), think where will be store the keys themselves. Think of Hardware Security Modules.
8. Unless your occupation is a security researcher, don't fall to the temptation of designing your own encryption algorithm. Security by obfuscation is just a bad idea.
9. Before storing any data, think about what you intend to do with it. Any customer data stored in your systems have potential to be leaked. Don't store a piece of data that you have no need for.
10. Pay attention to filtering rules for your logging and audit your logs for any accidental sensitive data reaching the logs.
11. Heed warning from compilers, lint, and other analysis tools. A sprint is done only when all the warnings have been removed.
12. In this time and age, don't use HTTP, Stick to HTTPS with at least TLS/1.2
13. Have a policy on employee turnover. Many times ex-employees may be the biggest source of data leakage. 
14. Specifically design and test against injection risks. Minimize native SQL queries as much as possible.
15. Specifically design and test against broken authentication and authorization. Many systems suffer from issues such as users assuming identities of other users, users able to authorize themselves for higher roles etc. Take the help of a security researcher if you don't have staff on the team.
16. Each piece of data collected and stored should be specifically annotated with the level of privacy and encryption required. Detailed thought related to the type of data needs to be given right at the design stage.
17. Auditing sensitive data is mandatory. The system needs to have an audit system built that can help us retrieve sufficient breadcrumbs in case of a customer complaint about data compromise.

These are some of the items that I could think of. Comment with your thoughts.

What are some fundamentals of security every developer should understand?
OWASP Top 10 - 2017