Validating and Sanitizing Input

Here is the defense you write when you are thinking about what to block:

if (preg_match('/<script|onerror|onload|javascript:/i', $_POST['comment'])) {
    exit('Malformed comment');
}

It works right up to the payload that was written yesterday: <svg/onload=alert(1)> is clean if you only listed onerror, <details open ontoggle=alert(1)> skips both, <body onfocus=this.focus() tabindex=1> uses onfocus, <iframe srcdoc="<script>alert(1)</script>"> nests the tag you did filter inside an attribute you did not. A denylist is a bet that you have already imagined every hostile input — and the attacker's job is only to find one you missed. The vocabulary is open-ended: event handlers alone number more than seventy, encodings multiply them, and every new HTML feature adds more.

Flip the question. Instead of listing what is forbidden, state what you accept:

if (!preg_match('\A[a-z0-9_]{3,20}\z', $username)) {
    http_response_code(422);
    exit('Username must be 3-20 chars: a-z, 0-9, underscore');
}

An allowlist fails closed: input outside the grammar is rejected whether or not you have heard of it, and <svg/onload=alert(1)> never needs to be in a rule anywhere. Two details decide whether your allowlist is real:

• Anchor it. preg_match('/[a-z0-9]+/', $v) matches "!!!admin!!!" because a substring satisfies it. Use \A … \z, not ^ … $ — the $ anchor also matches before a trailing newline, so "abc\n" passes /^[a-z]+$/ while \A[a-z]+\z rejects it.
• Compare strictly. in_array($role, ['user', 'admin']) without true juggles types: "admin" == 0, null == "", and "1e2" == 100 all compare equal in loose mode, so an attacker sends role=0 or a scientific-notation string and walks past the gate. in_array($role, ['user', 'admin'], true) compares value and type.

Fields map cleanly to rules, and the rule is documentation you can point a reviewer at:

The three verbs people use as synonyms — validate, sanitize, escape — belong to three different moments, and collapsing them is exactly how invalid data survives review:

The sanitizer trap deserves its own warning: a silent rewrite lets invalid data through your logic wearing a valid costume. a1b2 → 12 sails past a min_range check the original input would have failed, and no error ever announces that it happened. PHP's own history backs the verdict — FILTER_SANITIZE_STRING was deprecated in 8.1 and removed in 8.2, because stripping tags is neither validation (the input should have been rejected outright) nor escaping (only the output context knows the right encoding).

Normalize before validating (trim(), lowercase for case-insensitive fields) and accept that invalid input dies here, before it reaches a query, a view, or a log line — that early rejection is what the next chapter builds on with PHP's own filter functions, and it is the same discipline CSRF Tokens for Forms applies to requests: one gate, fail closed, before any handler runs.

PHP ships typed validation for request data, and the type system of the filter API is where candidates lose points. Start with the function that reads the original request:

$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1, 'max_range' => 100000],
]);

if ($id === false || $id === null) {          // invalid, or not present at all
    http_response_code(422);
    exit('id must be an integer between 1 and 100000');
}

Three return meanings, distinguishable only with ===:

The absent-versus-invalid split is the interview question: filter_input(INPUT_POST, 'page') on a request with no page returns null, so if (!filter_input(...)) collapses "missing" and "broken" into one branch — fine when both should 422, wrong when a missing field should default to 10 and an invalid one should be rejected. filter_var() behaves the same way but reads a value you already hold; the difference matters when code elsewhere has mutated $_GET/$_POST — filter_input still sees what actually arrived on the wire.

Bulk validation keeps the shapes together:

$input = filter_input_array(INPUT_POST, [
    'email' => FILTER_VALIDATE_EMAIL,
    'qty'   => FILTER_VALIDATE_INT,
    'plan'  => ['filter' => FILTER_VALIDATE_REGEXP,
                'options' => ['regexp' => '/\A(pro|free)\z/']],
    'tags'  => ['filter' => FILTER_SANITIZE_FULL_SPECIAL_CHARS,
                'flags'   => FILTER_REQUIRE_ARRAY],
]);
if ($input === false || in_array(false, $input, true)) {
    http_response_code(422); exit('One or more fields are invalid');
}

The filters worth knowing by name:

That last row is the whole philosophy: sanitizers transform, validators decide. FILTER_SANITIZE_STRING was deprecated in PHP 8.1 and removed in 8.2 precisely because stripping tags produced strings nobody had actually validated — output escaping (see Escaping Output to Prevent XSS) belongs at the echo, and rejection belongs at the boundary. Validation placed there means invalid data never reaches a query, a view, or your logs, which is what the next chapter pressure-tests with JSON bodies, arrays pretending to be scalars, and uploaded files.

Validation earns its keep at the boundary — the front controller or route handler — and three input shapes are designed to slip past naive checks.

1. Arrays where you expected scalars. PHP happily parses ?id[]=1, ?id[foo]=bar, and role=admin&role[]=x:

$id = $_GET['id'];                     // int 42 or array — you don't get to choose
var_dump((int) ['1 OR 1=1']);          // int 1: a non-empty array casts to 1

Your cast "works", the query runs against id = 1 for every request, and production silently returns the wrong row instead of failing. Check the shape before the value:

if (!isset($_GET['id']) || !is_scalar($_GET['id'])) {
    http_response_code(422); exit('id must be a scalar');
}
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT, FILTER_REQUIRE_SCALAR);
if ($id === false || $id === null) { http_response_code(422); exit('bad id'); }

FILTER_REQUIRE_SCALAR plus is_scalar() closes the door that preg_match alone leaves open — in PHP 8, passing an array to preg_match() throws a TypeError, so the shape check must run first or your 422 becomes a 500 with a stack trace.

2. JSON bodies. filter_input() reads form-encoded GET/POST/cookie data, not php://input, so a JSON endpoint validates the decoded structure itself:

try {
    $data = json_decode(file_get_contents('php://input'), true, 8, JSON_THROW_ON_ERROR);
} catch (JsonException $e) {
    http_response_code(400); exit('Body must be valid JSON');
}
if (!is_array($data)) { http_response_code(422); exit('Expected a JSON object'); }

$email = filter_var($data['email'] ?? null, FILTER_VALIDATE_EMAIL);
$role  = in_array($data['role'] ?? '', ['user', 'admin'], true) ? $data['role'] : null;
if ($email === false || $role === null) { http_response_code(422); exit('email or role invalid'); }

Note ?? null before filtering: $data['email'] on a missing key is a notice and an undefined value, not a validation failure. Depth-limited json_decode (that 8) keeps a hostile payload from eating memory, and JSON_THROW_ON_ERROR turns "silently return null" into a catchable failure — json_last_error() checked after some other call is the classic race in review.

3. Files that lie about their type. $_FILES['avatar']['type'] is the client's claim — send Content-Type: image/png on a PHP shell and it says image/png:

$f = $_FILES['avatar'] ?? null;
if (!$f || $f['error'] !== UPLOAD_ERR_OK || $f['size'] > 2 * 1024 * 1024) { http_response_code(422); exit('bad upload'); }
if (!is_uploaded_file($f['tmp_name'])) { http_response_code(422); exit('not a real upload'); }

$mime = (new finfo(FILEINFO_MIME_TYPE))->file($f['tmp_name']);   // sniffed bytes, not the header
$allow = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
if (!isset($allow[$mime])) { http_response_code(422); exit('JPEG or PNG only'); }
$name = bin2hex(random_bytes(16)) . '.' . $allow[$mime];         // your name, never theirs
move_uploaded_file($f['tmp_name'], '/var/www/uploads/' . $name);

Extension, declared MIME, and sniffed MIME must all agree with your allowlist, and the stored name must be one you generated — a user-supplied filename is a path traversal (../../) and a stored XSS (x.html) in one string.

Two boundary rules finish the job. Client-side validation is courtesy, not control — curl deletes your JavaScript and replays the request, so every rule must exist server-side too. And reject before logging: a failed-validation log line should record the field name and the rule violated, not the raw password attempt or the full PII payload, or your logs become the leak you were defending against. That is the complete loop — reject at the gate, keep what passes typed and narrow — and the credentials that survive it get hashed in the next topic, Hashing Passwords Correctly.