1. Input Checking
Always check user input to be sure that it is what you expected.
Make sure it doesn’t contain characters or other data which may be treated in a special way
by your program or any programs called by your program.This often involves checking for characters
such as quotes, and checking for unusual input characters such as non-alphanumeric characters
where a text string is expected. Often, these are a sign of an attack of some kind being attempted.
Always check the ranges when copying data, allocating memory or performing any operation
which could potentially overflow. Some programming languages provide range-checked container access
(such as the std::vector::at() in C++, but many programmers insist on using the unchecked
array index  notation. In addition, the use of functions such as strcpy() should be avoided in
preference to strncpy(), which allows you to specify the maximum number of characters to copy.
Similar versions of functions such as snprintf() as opposed to sprintf() and fgets()
instead of gets() provide equivalent length-of-buffer specification. The use of such functions
throughout your code should prevent buffer overflows. Even if your character string originates
within the program, and you think you can get away with strcpy() because you know the length of
the string, that doesn’t mean to say that you, or someone else, won’t change things in the future
and allow the string to be specified in a configuration file, on the command-line, or from
direct user input. Getting into the habit of range-checking everything should prevent a large number
of security vulnerabilities in your software.
3.Principle Of Least Privileges
This is especially important if your program runs as root for any part of its runtime.
Where possible, a program should drop any privileges it doesn’t need, and use the higher privileges
for only those operations which require them. An example of this is the Postfix mailserver,
which has a modular design allowing parts which require root privileges to be run distinctly
from parts which do not. This form of privilege separation reduces the number of attack paths
which lead to root privileges, and increases the security of the entire system because those few paths
that remain can be analysed critically for security problems.
A race condition is a situation where a program performs an operation in several steps,
and an attacker has the chance to catch it between steps and alter the system state.
An example would be a program which checks file permissions, then opens the file.
Between the permission check the stat() call and the file open the fopen() call an attacker
could change the file being opened by renaming another file to the original files name.
In order to prevent this, fopen() the file first, and then use fstat(), which takes a
file descriptor instead of a filename. Since a file descriptor always points to the file
that was opened with fopen(), even if the filename is subsequently changed, the fstat() call
will be guaranteed to be checking the permissions of the same file.
Many other race conditions exist, and there are often ways to prevent them by carefully
choosing the order of execution of certain functions.
5.Register Error Handlers
Many languages support the concept of a function which can be called when an error is detected,
or the more flexible concept of exceptions. Make use of these to catch unexpected conditions and
return to a safe point in the code, instead of blindly progressing in the hope that the user input
won’t crash the program, or worse!