Skip to content

CWE-234: Failure to Handle Missing Parameter

Overview

Failure to handle missing parameters occurs when an application reads a required input parameter without confirming it was supplied. The absent value reaches code that assumes it is there, which can crash the request, skip an authentication or authorization check, or fall back to an unsafe default.

Relationship to Other CWEs

MITRE marks CWE-234 Discouraged for mapping new vulnerabilities and notes it "could be deprecated in a future version of CWE." The maintenance notes explain why: the entry historically conflated two different ideas, and both readings are still live on MITRE's page. The observed examples and classification came from PLOVER and describe a missing request parameter, while the description text - "If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack" - and the demonstrative example came from CLASP.

A CWE-234 finding therefore has to be read before it is acted on. If it is about a request, form, or API call arriving without a parameter the handler requires, this page applies directly. If it is about a call site passing fewer arguments than the function declares, this page is the wrong one.

OWASP Classification

A10:2025 - Mishandling of Exceptional Conditions

Risk

Medium: A missing required parameter can crash the application through a null pointer exception or an uninitialized variable, which is a denial of service. It can also let code skip an authentication or authorization check, or fall back to an incorrect default - worst of all when the absent parameter is a token or permission flag that a security decision reads.

Remediation Steps

Core Principle: Treat every required parameter as absent until it has been explicitly validated as present with an acceptable value; fail closed on missing input, especially when the parameter feeds an authentication, authorization, or other security decision.

Locate Missing Parameter Handling Issues

Look for:

  • Code that reads a request parameter without first confirming it was supplied
  • Authentication and authorization flows that never check the token or permission parameter is present
  • API endpoints whose required parameters are not validated
  • Null pointer or undefined-value exceptions that trace back to a missing parameter
  • Places where a missing parameter silently falls back to an unsafe default

Validate Required Parameters Are Present (Primary Defense)

// VULNERABLE - pseudo-code
function get_user(request):
    user_id = request.params.id          // no check that "id" was actually supplied
    return db.find_by_id(user_id)         // undefined/null id reaches the query layer

function transfer(request):
    amount = request.body.amount
    to_account = request.body.to
    do_transfer(amount, to_account)       // missing amount silently becomes undefined

// SECURE - pseudo-code
function get_user(request):
    if "id" not in request.params:
        return error(400, "Missing required parameter: id")
    if not is_valid_id_format(request.params.id):
        return error(400, "Invalid id format")
    user = db.find_by_id(request.params.id)
    if not user:
        return error(404, "User not found")
    return user

function transfer(request):
    required = ["amount", "to", "from"]
    missing = [field for field in required if field not in request.body]
    if missing:
        return error(400, "Missing required fields", missing)
    if not is_positive_number(request.body.amount):
        return error(400, "Invalid amount")
    do_transfer(request.body.amount, request.body.to, request.body.from)

Why this works: Explicitly checking for missing parameters before use prevents null/undefined values from reaching business logic, where they'd otherwise cause crashes, silent logic errors, or a skipped security check. Fail fast with a clear 400-level error rather than letting the code guess.

Use a Schema Validation Framework

Manually checking each field is easy to get wrong as an API grows. A schema validation library (Joi and Zod for Node.js, Pydantic for Python, Bean Validation/@NotNull for Java, FluentValidation for .NET) lets you declare required vs. optional fields once, validate the whole payload in one pass, and reject unknown or malformed fields alongside missing ones - closing the gap where a manual if (a && b && c) check quietly misses a field that was added later.

Handle Security-Critical Parameters Correctly

// SECURE - pseudo-code
function require_auth(handler):
    return function(request):
        token = request.headers["Authorization"]
        if not token or not token.starts_with("Bearer "):
            return error(401, "Missing or invalid authorization")
        user = verify_token(strip_prefix(token, "Bearer "))
        if not user:
            return error(401, "Invalid token")
        return handler(request, user)

function delete_user(request, user, target_id):
    // Never default a permission check to true when the field is absent
    if not user.is_admin:
        return error(403, "Insufficient permissions")
    db.delete(User, target_id)

An absent authorization header, permission flag, or role claim must be treated as "not authorized," never as "assume the safe case." A validation framework that silently defaults an optional boolean to true turns a missing field into a privilege escalation.

Provide Safe Defaults Only for Optional Parameters

Defaults are appropriate for genuinely optional, non-security fields - a page size, a sort order, a display locale. They are never appropriate for a parameter that a security decision reads: an includePrivate, isAdmin, or bypassCheck-style flag must be required and explicitly validated, not defaulted to the permissive value when the client omits it.

Test Missing Parameter Handling

  • Send requests with each required field omitted in turn and confirm a 400-level response naming the missing field
  • Send requests with no Authorization header and confirm a 401, not a crash or a request processed as anonymous-but-privileged
  • Confirm optional parameters fall back to safe, non-privileged defaults when omitted
  • Confirm a fully valid request (all required fields present) still succeeds
  • Re-scan with the security scanner to confirm the finding is resolved

Common Vulnerable Patterns

  • Reading a request parameter and using it without checking it was supplied
  • Assuming a query-string or route parameter is always present
  • Missing null/undefined checks before using a parameter in logic or a query
  • Silently proceeding (or silently succeeding) when a required parameter is absent
  • Defaulting a security-critical parameter (permission flag, role, token) to a permissive value when it's missing

Common Pitfalls

  • Checking truthiness instead of presence: if (param) rejects legitimate falsy-but-valid values like 0, false, or "" as if they were missing, while still letting other missing-value representations slip through depending on the language - check for presence explicitly (in, hasOwnProperty, is None), not truthiness.
  • Validating presence on only one code path: a handler that checks a required field on POST but not on PUT/PATCH to the same resource leaves the identical bug reachable through a different verb or a different endpoint that shares the same logic.
  • Defaulting a security-critical parameter to the permissive value: using true as the default for includePrivate or isAdmin when the field is omitted turns "the client forgot to send a flag" into an authorization bypass - safe defaults belong on pagination and formatting fields, never on anything a security decision reads.
  • Trusting client-side or documentation-only "required" markers: a required field in a front-end form or an OpenAPI schema doesn't stop a raw HTTP request from omitting it - validation has to happen against the actual request on the server, not the client's or the spec's promise that the field would be there.

Additional Resources