MET01-J. Validate method parameters

Validate method parameters to ensure that they fall within the bounds of the method's intended design. This practice ensures that operations on the method's parameters yield valid results. Failure to validate method parameters can result in incorrect calculations, runtime exceptions, violation of class invariants and inconsistent object state.

Redundant testing of parameters by both the caller and the callee is a style of defensive programming that is largely discredited within the programming community, in part for reasons of performance. Instead, normal practice requires validation on only one side of each interface.

Caller validation of parameters can result in faster code, because the caller may be aware of invariants that prevent invalid values from being passed. Conversely, callee validation of parameters encapsulates the validation code in a single location, reducing the size of the code and raising the likelihood that the validation checks are performed consistently and correctly.

If a method receives data from across a trust boundary, that method must perform callee validation of its parameter for safety and security reasons. This applies to all public methods of a library. Other methods, including private methods, should validate arguments that are both untrusted and unvalidated when those arguments may propagate from a public method via its arguments.

When defensive copying is necessary, make the defensive copies before parameter validation, and validate the copies rather than the original parameters. See guideline SER07-J. Make defensive copies of private mutable components for additional information.

Noncompliant Code Example

In this noncompliant code example, setState() and useState() fail to validate their parameters. A malicious caller could pass an invalid state to the library, consequently corrupting it and exposing a vulnerability.

private Object myState = null;

// Sets some internal state in the library 
void setfile(Object state) {
  myState = state;
}

// Performs some action using the file passed earlier 
void useState() {
  // Perform some action here 
}

Such vulnerabilities are particularly severe when the internal state references sensitive or system-critical data.

Compliant Solution

This compliant solution validates the method parameters and also verifies the internal state before use. This promotes consistency in program execution and reduces potential for vulnerabilities.

private Object myState = null;

// Sets some internal state in the library 
void setfile(Object state) {
  if (state == null) {
    // Handle null state 
  }

  // Defensive copy here when state is mutable

  if (isInvalidState(state)) {
    // Handle invalid state 
  }
  myState = state;
}

// Performs some action using the state passed earlier 
void useState() {
  if (myState == null) {
    // Handle no state (e.g. null) condition
  }
  // ...
}

Exceptions

MET01-EX0: Parameter validation inside a method may be omitted when the stated contract of a method requires that the caller must validate arguments passed to the method. In this case, the validation must be performed by the caller for all invocations of the method.

MET01-EX1: Parameter validation may be omitted for parameters whose type adequately constrains the state of the parameter. This constraint should be clearly documented in the code.

This may include parameters whose values (as permitted by their type) are not necessarily valid, but are still correctly handled by the function. In the following code, no explicit validation is done of the arguments x and y even though their product might not be a valid int. The code is safe as it adequately handles all int values for x and y.

public int product(int x, int y) {
  long result = (long) x * y;
  if (result < Integer.MIN_VALUE || result > Integer.MAX_VALUE) {
    // handle error
  }
  return (int) result;
}

MET01-EX2: Complete validation of all parameters of all methods may introduce added cost and complexity that exceeds its value for all but the most critical code. See, for example, NUM00-J. Detect or prevent integer overflow exception NUM00-EX2. In such cases, consider parameter validation at API boundaries, especially those that may involve interaction with untrusted code.

Risk Assessment

Failure to validate method parameters can result in inconsistent computations, runtime exceptions, and control flow vulnerabilities.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

[[Bloch 2008]] Item 38: Check parameters for validity

MET00-J. Avoid ambiguous uses of overloading      05. Methods (MET)      MET02-J. Never use assertions to validate method parameters