Writing Secure Code

Do think about the access controls your application explicitly places on objects, and the access controls objects inherit by default.

Do realize that some data is so sensitive it should never be stored on a general purpose, production serverfor example, long-lived X.509 private keys, which should be locked away in specific hardware designed to perform only signing.

Do leverage the operating system capabilities to secure secret and sensitive data.

Do use appropriate permissions, such as access control lists (ACLs) or Permissions if you must store sensitive data.

Do remove the secret from memory once you have used it.

Do scrub the memory before you free it.

Do not create world-writable objects in Linux, Mac OS X, and UNIX.

Do not create objects with Everyone (Full Control) or Everyone (Write) access control entries (ACEs).

Do not store key material in a demilitarized zone (DMZ). Operations such as signing and encryption should be performed further back than the DMZ.

Do not embed secret data of any kind in your application. This includes passwords, keys, and database connection strings.

Do not embed secret data of any kind in sample applications, such as those found in documentation or software development kits.

Do not create your own secret encryption algorithms.

Consider using encryption to store information that cannot be properly protected by an ACL, and signing to protect information from tampering.

Consider never storing secrets in the first placecan you get the secret from the user at run time instead?