Why PHP filter_input() Returns NULL

When filter_input() returns NULL, it is tempting to treat the value as an empty string or a failed validation. Those are different states. A missing input variable and a value that fails a validation filter should lead to different handling in your application.

Distinguish missing from invalid

For a request parameter that should be an integer, a simple check looks like this:

$page = filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT);
if ($page === null) {
    // The input variable was not present in this request.
} elseif ($page === false) {
    // It was present, but failed integer validation.
} else {
    // $page is a validated integer.
}

Use strict comparisons. A truthiness check can confuse zero with failure. PHP documents the return behavior and available filters in the filter_input() reference.

Check the input source and runtime

The first argument must match where the value came from: INPUT_GET, INPUT_POST, or another supported input type. A command-line script has no ordinary browser query string, so a test performed in CLI may not reproduce a web request. Also verify the field name exactly; an HTML form's name attribute becomes the request key.

Do not assume FILTER_DEFAULT sanitizes hostile input. It is equivalent to raw input. Choose a filter for the expected data type, then apply context-appropriate output escaping when rendering data.

Make the failure visible during debugging

Temporarily log whether the value was absent or invalid, without recording passwords, tokens or unnecessary personal data. Reproduce with one request that omits the key and another that sends a malformed value. That small comparison often exposes a form-name mismatch or a test running in the wrong SAPI.

Keep validation near the point where input enters the application, and still enforce business rules such as permitted ranges. Type validation alone does not establish that a page number or account ID is authorized.