1. Assume whatever can go wrong will.
Example: Never use gets().
2. Assume any input is going to be malformed or not what you expect.
Example: Check validity of input parameters.
3. Do not make a security decision based on untrusted inputs.
Example: Avoid Double-Free vulnerabilities.
4. Check parameters to ensure that all arguments are of the correct type and will not overflow any arrays.
Example: Improperly bounded string copies.
5. Use data abstraction to enable the compiler to perform rigorous type checking and to enforce constraints on values and lengths.
Example: Implicit type
6. Understand the context in which the program will execute.
Example: Deadlock in a multi-threaded program.
7. Validate your input stream to ensure that the commands invoked are expected and no other commands are injected.
8. When performing input validation take into account how programs invoked with those arguments could interpret them.
9. Avoid hard-coded passwords and secrets in your program.
Example: Storing passwords in plaintext .
10. Use well known and accepted cryptographic algorithms and implementations of those algorithms.
Don't use obsolete or deprecated cryptographic algorithms or create your own algorithms.
11. Use well known and accepted cryptographic random number generation.Don't use obsolete or deprecated cryptographic algorithms or create your own
12. There are many tools to help you create a secure program, please take advantage of them. Example: SPC Clinic
A. If you have no reason to trust it, don't trust it.Take greater care with any input you have not generated.
Example: Check the validity of input parameters.
B. If it cannot happen, check for it. Someone may modify the program in such a way that it can happen... or you may be wrong.
C. Do not use input or constructor string functions that do not perform any bound checking.
D. Do not use input or constructor functions that cannot check the length of the input. Example: Using gets( ) causes buffer overflow. Use fgets( ) instead.
E. C and C++ compilers generally do not check types rigorously. A developer can increase this level of checking by turning or compiler warnings, which will often
catch more type errors than if they are not used. Some examples are given below:
F. Avoid calls to malloc( ) with parameter (number of bytes to be allocated)set to 0. Either the function returns NULL, or it returns a pointer to space that cannot
be used without overwriting unallocated memory.
G. Control the input values when possible by limiting them to a finite set. Some examples are given below.
(a) Example 1.
(b) Example 2.
H. Calling functions with null parameters for input should be checked and defended against.
I. Type conversion issues especially for cases that may result in integer wrap-around and overflows.
Example: Non-compliant comparisons.
J. Rules for pointer arithmetic as vulnerabilities can arise when addition or size checks involve two pointer types.
Example: Arithmetic involves two pointer types.
K. When performing input validation make sure that any validated path does not allow escaping from a restricted directory.
L. Before creating a directory or file, make sure you have set the correct default permission specification.
M. Be wary of off-by-one errors. Some examples are given below.
N. When using format string functions, make sure that the format string can be authenticated/trusted. Some examples are given below.
(b) Buffer Overflow.
i. Hide details that users don't need to know about. Some examples are given below.
ii. Avoid side effects in arguments to unsafe macros. If developer is using a macro that uses its arguments more than once, then the developer must avoid passing any
arguments with side effects to that macro.
Example: Using unsafe macros.
iii. Use parentheses around macro replacement lists. Otherwise operator precedence may cause the expression to be computed in unexpected ways.
iv. Minimise the scope of variables and functions, This prevents many unexpected changes to the variables due to programming error.
v. When the memory a pointer points to is freed, the pointer should be reset to NULL. Otherwise, these dangling pointers could cause writing to freed memory, and cause
a double free.
Example: Avoid double-free vulnerabilities