...
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
...
...
, 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.
| Code Block | ||
|---|---|---|
| ||
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. h2. 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|https://www.securecoding.cert.org/confluence/display/java/BB.+Definitions#BB.Definitions-vulnerability]. {code:bgColor=#FFcccc} private Object myState = null; // Sets some internal state in the library void setfilesetState(Object state) { myState = state; } // Performs some action using the filestate passed earlier void useState() { // Perform some action here } {code} |
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.
| Code Block | ||
|---|---|---|
| ||
parameters and also verifies the internal state before use. This promotes consistency in program execution and reduces potential for vulnerabilities. {code:bgColor=#ccccff} private Object myState = null; // Sets some internal state in the library void setfilesetState(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 } // ... } {code} h2.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}}. {code:bgColor=#ccccff} |
Exceptions
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.
| Code Block | ||
|---|---|---|
| ||
public int product(int x, int y) {
long result = (long) x * y;
if (result < Integer.MIN_VALUE || result > Integer.MAX_VALUE) {
// handleHandle error
}
return (int) result;
}
}code{
*MET01 |
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
...
...
code.
...
Risk
...
Assessment
...
Failure
...
to
...
validate
...
method
...
arguments can
...
result
...
in
...
inconsistent
...
computations,
...
runtime
...
exceptions,
...
and
...
control
...
flow
...
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
MET00-J | High | Likely | High | P9 | L2 |
Related Guidelines
Argument Passing to Library Functions [TRJ] |
Bibliography
Item 38, "Check Parameters for Validity" |
...