Is it good or bad manner to oversecure?

Question

If a function does all proper checks inside, should I check everything before calling it, or better not? Is security redundancy considered a good practice?

Example (in a sort of C#-like pseudocode with by-reference arguments passing):

doSomething(vector v) {
  ...;
  v.clear;
  useCleanVector(v)
}

useCleanVector(vector v) {
  if(!v.isClean) v.clear;
  ...
}

Answer 1

I'd say it's bad form. Not terrible form but the same kind of form that leads to this:

 v.clear(); // clear the vector to be safe. 
 v = v2;

If your manner is to reproduce the code that's already inside a function, then you're not saving time by having it in the function in the first place. You're violating the DRY concept if every call to a function has the same preamble.

It's best to understand what the function does check and what it doesn't and use it accordingly.

Answer 2

What matters most is that you document your preconditions, and exceptional conditions in an obvious way. Something like this seems sensible.

/**
 * precondition : id must be the id of a flarg.
 * 
 * myfunc will return -1 if value is outside the valid 0-10 range.
 */
int myfunc( int id, int value );

This lets me code something like this

 int flarg_id = ...
 if (! is_flarg( flarg_id ) ) { printf("Bad flarg"); exit(1); }
 int value = ...
 int rv = myfunc( flarg_id, value );
 if( rv == -1 )  { printf("Bad value"); exit(1); }

Answer 3

Yes you should always perform the needed checks at that level of scope.

The reason? When someone comes in after you in n months, they are not going to follow the function calls down to the last item. Making sure that each function is protected in and of itself will help alleviate silly bugs or worse yet, bugs which are difficult to track down.

Answer 4

There's redundancy (often good), and there's repeating yourself.

To borrow from Josh's example, if function Foo guarantees that it clears a vector, there's no reason to clear it beforehand. Trust-and-verify the guarantees your API provides.

On the other hand, even if you're confident that a data access surface is completely secured against any malicious activity (you checked every procedure pre- and post- conditions yourself!), there's no reason to expose that surface to unauthorized users. Find your bottlenecks, and secure those, just in case code deeper in has vulnerabilities you don't know about yet.