Skip to end of metadata
Go to start of metadata

Validate method arguments 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 arguments can result in incorrect calculations, runtime exceptions, violation of class invariants, and inconsistent object state.

Redundant testing of arguments 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 arguments can result in faster code because the caller may be aware of invariants that prevent invalid values from being passed. Conversely, callee validation of arguments 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.

Methods that receive arguments across a trust boundary must perform callee validation of their arguments for safety and security reasons. This precaution 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 argument validation, and validate the copies rather than the original arguments (see SER06-J. Make defensive copies of private mutable components during deserialization for additional information).

Noncompliant Code Example

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

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

Compliant Solution

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


MET00-J-EX0: Argument 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.

MET00-J-EX1: Argument validation may be omitted for arguments whose type adequately constrains the state of the argument. This constraint should be clearly documented in the code.

This exception may apply to arguments whose values (as permitted by their type) are not necessarily valid but are still correctly handled by the method. In the following code, the arguments x and y are not validated even though their product might not be a valid int. The code is safe because it adequately handles all int values for x and y.

MET00-J-EX2: Complete validation of all arguments of all methods may introduce added cost and complexity that exceeds its value for all but the most critical code. In such cases, consider argument validation at API boundaries, especially those that may involve interaction with untrusted code.

Risk Assessment

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




Remediation Cost









Related Guidelines

ISO/IEC TR 24772:2010

Argument Passing to Library Functions [TRJ]


[Bloch 2008]

Item 38, "Check Parameters for Validity"



  1. Hi there..

    setfile() method should changed to setState() according to explanation in the non compliant code example above.


  2. What are these supposed to be?:
        // Handle null state
        // Handle invalid state
        // Handle no state (e.g. null) condition
        // handle error

    Presumably they should be just throwing NullPointerException, IllegalArgumentException, some kind of Error/NPE and IllegalArgumentException, respectively.

    1. Yes, presumably. But we don't require them to. For instance, if state is null, you could throw MyOwnNullException rather than java.lang.NullPointerException. Which is why we leave the error handling as an exercise to the developer (smile)