Page History

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

It if Programmers often assumed assume that validation of arguments passed to private methods do not require any validation because they are not directly accessible from is unnecessary because such methods cannot be accessed directly by code present outside the their enclosing class. This assumption is misleading as programming incorrect. Programming errors often arise as a result of when legitimate code misbehaving behaves in unanticipated ways. For example, a tainted value may propagate from a public API to one of the internal a private methods via its parameters.

AssertionsNever shoulduse notassertions be usedshould to validate parameters of {{public}} methods. According to the Java Language Specification \[[JLS 2005|AA. Bibliography#JLS 05]\], Section 14.10 "The {{assert}} Statement"

Along similar lines, assertions should not be used for argument-checking in public methods. Argument-checking is typically part of the contract of a method, and this contract must be upheld whether assertions are enabled or disabled.

Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException or NullPointerException). An assertion failure will not throw an appropriate exception. Again, it is not illegal to use assertions for argument checking on public methods, but it is generally inappropriate.

Also note that any defensive copying must be performed before validating the parameters and the checks must be performed on the copies instead of When defensive copying is necessary, make the defensive copies before parameter validation; validate the copies rather than the original parameters. (See guideline SER07-J. Make defensive copies of private mutable components.)

Noncompliant Code Example

The method AbsAdd() takes computes and returns the sum of the absolute value of parameters x and y and returns their sum. It does not perform any validation on the input and consequently, lacks parameter validation. Consequently, it can produce incorrect results because of either due to integer overflow or a negative number being returned from the computation or when either or both of its arguments are Math.abs(Integer.MIN_VALUE).

...

public static int AbsAdd(int x, int y) {
  assert x != Integer.MIN_VALUE;
  assert y != Integer.MIN_VALUE;
  assert ((x <= Integer.MAX_VALUE - y));
  assert ((x >= Integer.MIN_VALUE - y));
  return Math.abs(x) + Math.abs(y);
}

The conditions checked by the assertions are reasonable. However, the validation code is omitted when executing with assertions turned off.

Compliant Solution

This compliant solution validates the input method arguments by ensuring that values passed to Math.abs() to ensure it is not exclude Integer.MIN_VALUE and checks also by checking for integer overflow. The Alternatively, the addition could be performed using type long and the result of the computation can also be addition stored in a long variable to avoid overflow. However, in this case, the upper bound of the addition is required to be representable as the type int.local variable of type long. This alternate implementation would require a check to ensure that the resulting long can be represented in the range of the type int. Failure of this latter check would indicate that an int version of the addition would have overflowed.

public static int AbsAdd(int x, int y) {
  if((x == Integer.MIN_VALUE || y == Integer.MIN_VALUE) ||
    (x>0 && y>0 && (x > Integer.MAX_VALUE - y)) || 
    (x<0 && y<0 && (x < Integer.MIN_VALUE - y)))
      throw new IllegalArgumentException();

  return Math.abs(x) + Math.abs(y);
}

Exceptions

MET02-EX1: 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.

MET02-EX2: 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.

MET02-EX3: 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

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

Automated Detection

...

Related Vulnerabilities

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

Bibliography

\[[JLSBloch 20052008|AA. Bibliography#JLSBibliography#Bloch 0508]\] 14.10 The assert StatementItem 38: Check parameters for validity
\[[BlochDaconta 20082003|AA. Bibliography#BlochBibliography#Daconta 0803]\] Item 387: My CheckAssertions parametersAre forNot validityGratuitous
\[[ESA 2005|AA. Bibliography#ESA 05]\] Rule 68: Explicitly check method parameters for validity, and throw an adequate exception in case they are not valid. Do not use the assert statement for this purpose
\[[DacontaJLS 20032005|AA. Bibliography#DacontaBibliography#JLS 0305]\] Item 7: My Assertions Are Not Gratuitous14.10 The assert Statement

...

MET01-J. Avoid ambiguous uses of overloading      05. Methods (MET)