Defensive programming

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. Defensive programming practices are often used where high availability, safety, or security is needed.
Defensive programming is an approach to improve software and source code, in terms of:
Overly defensive programming, however, may safeguard against errors that will never be encountered, thus incurring run-time and maintenance costs. There is also a risk that code traps prevent too many exceptions, potentially resulting in unnoticed, incorrect results.
Secure programming.
Secure programming is the subset of defensive programming concerned with computer security. Security is the concern, not necessarily safety or availability (the software may be allowed to fail in certain ways). As with all kinds of defensive programming, avoiding bugs is a primary objective; however, the motivation is not as much to reduce the likelihood of failure in normal operation (as if safety was the concern), but to reduce the attack surface – the programmer must assume that the software might be misused actively to reveal bugs, and that bugs could be exploited maliciously.
int risky_programming(char *input) {
 char str[1000]; 
 // ...
 strcpy(str, input); // Copy input.
 // ...
The function will result in undefined behavior when the input is over 1000 characters. Some novice programmers may not feel that this is a problem, supposing that no user will enter such a long input. This particular bug demonstrates a vulnerability which enables buffer overflow exploits. Here is a solution to this example:
int secure_programming(char *input) {
 char str[1000+1]; // One more for the null character.
 // Copy input without exceeding the length of the destination.
 strncpy(str, input, sizeof(str)); 
 // If strlen(input) >= sizeof(str) then strncpy won't null terminate. 
 // We counter this by always setting the last character in the buffer to NUL,
 // effectively cropping the string to the maximum length we can handle.
 // One can also decide to explicitly abort the program if strlen(input) is 
 // too long.
 str[sizeof(str) - 1] = '\0';
Offensive programming.
Offensive programming is a category of defensive programming, with the added emphasis that certain errors should "not" be handled defensively. In this practice, only errors from outside the program's control are to be handled (such as user input); the software itself, as well as data from within the program's line of defense, are to be trusted in this methodology.
Trusting internal data validity.
const char* trafficlight_colorname(enum traffic_light_color c) {
 switch (c) {
 case TRAFFICLIGHT_RED: return "red";
 case TRAFFICLIGHT_YELLOW: return "yellow";
 case TRAFFICLIGHT_GREEN: return "green";
 return "black"; // To be handled as a dead traffic light.
 // Warning: This last 'return' statement will be dropped by an optimizing
 // compiler if all possible values of 'traffic_light_color' are listed in
 // the previous 'switch' statement...
const char* trafficlight_colorname(enum traffic_light_color c) {
 switch (c) {
 case TRAFFICLIGHT_RED: return "red";
 case TRAFFICLIGHT_YELLOW: return "yellow";
 case TRAFFICLIGHT_GREEN: return "green";
 assert(0); // Assert that this section is unreachable.
 // Warning: This 'assert' function call will be dropped by an optimizing
 // compiler if all possible values of 'traffic_light_color' are listed in
 // the previous 'switch' statement...
Trusting software components.
if (is_legacy_compatible(user_config)) {
 // Strategy: Don't trust that the new code behaves the same
 old_code(user_config);
} else {
 // Fallback: Don't trust that the new code handles the same cases
 if (new_code(user_config) != OK) {
 old_code(user_config);
// Expect that the new code has no new bugs
if (new_code(user_config) != OK) {
 // Loudly report and abruptly terminate program to get proper attention
 report_error("Something went very wrong");
 exit(-1);
Techniques.
Here are some defensive programming techniques:
Intelligent source code reuse.
If existing code is tested and known to work, reusing it may reduce the chance of bugs being introduced.
However, reusing code is not "always" a good practice, because it also amplifies the damages of a potential attack on the initial code. 
Legacy problems.
Before reusing old source code, libraries, APIs, configurations and so forth, it must be considered if the old work is valid for reuse, or if it is likely to be prone to legacy problems.
Legacy problems are problems inherent when old designs are expected to work with today's requirements, especially when the old designs were not developed or tested with those requirements in mind.
Many software products have experienced problems with old legacy source code; for example:
Notable examples of the legacy problem:
Canonicalization.
Malicious users are likely to invent new kinds of representations of incorrect data. For example, if a program attempts to reject accessing the file "/etc/passwd", a cracker might pass another variant of this file name, like "/etc/./passwd". Canonicalization libraries can be employed to avoid bugs due to non-canonical input.
Low tolerance against "potential" bugs.
Assume that code constructs that appear to be problem prone (similar to known vulnerabilities, etc.) are bugs and potential security flaws. The basic rule of thumb is: "I'm not aware of all types of security exploits. I must protect against those I "do" know of and then I must be proactive!".