Check that input data is what the program expects by performing type, length, and bound checking. Inputs include command-line arguments and environment variables in addition to data that a user enters.

Check input data for the inclusion of constructs such as shell commands, SQL statements, and XML and HTML code that might be used in an injection attack.

Check the type, length, and bounds of arguments to system calls and library routines. If possible, use library routines that guard against buffer overflows.

Use full pathnames for file-name arguments, do not use files in world-writable directories, verify that a file being written to is not actually a symbolic link, and protect against the unintended overwriting of existing files.

Check the type, length, and bounds of values returned by system calls and library routines. Make the code respond appropriately to any error codes that system calls and library functions set or return.

Do not assume the state of the shell environment. Check any settings that a program inherits from the shell, such as the user file-creation mask, signal handling, file descriptors, current working directory, and environment variables, especially PATH and IFS . Reset the settings if necessary.

Perform assert checking on variables that can take a finite set of values.

Log information about privileged actions and error conditions. Do not allow the program to dump a core file on an end-user system.

Do not echo passwords to the screen, or transmit or store them as clear text. Before transmitting or storing a password, combine it with a salt value and use a secure one-way algorithm such as SHA-512 to create a hash.

If your program uses a pseudo-random number generating routine, verify that the numbers that it generates are sufficiently random for your requirements. You should also use a good random seed that a potential attacker should not be able to predict. See RFC 4086, Randomness Requirements for Security, for more information.

It is recommended that Address Space Layout Randomization (ASLR) is enabled on the host system as this feature can help defeat certain types of buffer overflow attacks. See Section 3.15.1, “Address Space Layout Randomization”.

When compiling and linking your program, use the Position Independent Executables (PIE) feature to generate a position-independent binary. See Section 3.15.3, “Position Independent Executables”.

Consider using chroot() to confine the operating boundary of your program to a specified location within a file system.

Do not execute a shell command by calling popen() or syscall() from within a program, especially from a setuid or setgid program.

Do not set the setuid or setgid bit on shell scripts. However, if you use Perl scripts that are setuid or setgid, perl runs in taint mode, which is claimed to be more secure than using the equivalent C code. See the perlsec(1) manual page for details.

Restrict the use of the privilege that setuid or setgid grants to the functionality that requires it, and then return the effective UID or GID to that of the user. If possible, perform the privileged functionality in a separate, closely-monitored thread or process.

Do not allow a setuid or setgid program to execute child processes using execlp() or execvp(), which use the PATH environment variable.