PHP unserialize Security: Move Untrusted Data to Validated JSON

Follow the warning on the actual PHP function

The PHP unserialize manual warns against passing untrusted input to the function, regardless of the allowed_classes option. Object restoration can involve behaviors beyond reading passive values. Do not present a restrictive option as proof that an arbitrary public input is safe.

Map where serialized data enters the system: uploaded settings, cookies, API bodies, database columns, cache records and background jobs. A database value is not automatically trusted if a public request could originally write it. Identify the producer and the integrity controls around each path.

This review does not require constructing an exploitation chain. A clear finding that an unauthenticated input reaches object deserialization is already a reason to redesign that boundary and assess exposure.

Choose a data contract before replacing the parser

A preference object might only need a theme and a page size. Define those fields, their types, accepted values and a size limit. Decide whether missing fields use a documented default or are rejected, and whether unknown fields are allowed. Consistency matters more than accepting every shape a parser can produce.

The OWASP deserialization guidance recommends safer interchange formats for PHP use cases. JSON can represent the simple data required here without restoring arbitrary application classes. It does not automatically validate a business schema, authorize a user or make strings safe to insert into HTML or SQL.

An original bounded preferences parser

The following PHP 8.x example accepts a small JSON object and returns only approved fields. It is a helper, not a complete import endpoint. The caller must enforce authentication, authorization, request/body limits and an appropriate response on validation failure.

<?php
function parseImportedPreferences(string $body): array
{
    if ($body === '' || strlen($body) > 8192) {
        throw new InvalidArgumentException('Invalid preferences size.');
    }
    $decoded = json_decode($body, false, 16, JSON_THROW_ON_ERROR);
    if (!$decoded instanceof stdClass) {
        throw new InvalidArgumentException('Preferences must be an object.');
    }
    $fields = get_object_vars($decoded);
    if (array_diff(array_keys($fields), ['theme', 'pageSize']) !== []) {
        throw new InvalidArgumentException('Unknown preference field.');
    }
    $theme = $fields['theme'] ?? 'system';
    $pageSize = $fields['pageSize'] ?? 20;
    if (!is_string($theme)
        || !in_array($theme, ['light', 'dark', 'system'], true)) {
        throw new InvalidArgumentException('Invalid theme.');
    }
    if (!is_int($pageSize)
        || !in_array($pageSize, [20, 50, 100], true)) {
        throw new InvalidArgumentException('Invalid page size.');
    }
    return ['theme' => $theme, 'pageSize' => $pageSize];
}

The json_decode reference documents depth, decoding behavior and JSON_THROW_ON_ERROR. Handle JsonException and validation exceptions at the HTTP boundary with controlled messages. Do not expose an internal stack trace to the visitor.

This contract deliberately treats null like an omitted value because the null-coalescing defaults do so. If the product needs to reject null, distinguish field presence with array_key_exists() and add a corresponding test. Security reviews improve when such behavior is explicit rather than accidental.

Do not move the same unsafe behavior behind a fallback

A migration that tries JSON and, on failure, calls unserialize() on the original request preserves the dangerous input path. Use an explicit new format version and reject unsupported public formats. Route any necessary legacy conversion through a separate, tightly controlled process.

For historical server-owned records, first establish provenance and restrict the migration job's environment and permissions. Keep backups, record conversion outcomes and make the migration resumable. If a record's origin or integrity is uncertain, do not process it casually in a privileged production worker. Escalate that subset for a safer migration design.

Deploy readers and writers in an order that accounts for old workers and queued messages. Version cache keys or expire obsolete entries intentionally. An apparently complete web deployment may still have a scheduled task writing the old format.

Authentication and integrity remain separate requirements

If a system uses signatures for data transported outside its trust boundary, the integrity design must include key management, verification and replay/version rules. A signature is not a license to accept every data structure, and an untrusted sender must not choose the verification key.

For ordinary user preferences, a validated JSON contract and normal authenticated application flow are generally easier to reason about than a custom object transport. Continue authorizing the account being modified. A correctly parsed document for another user's account must still be rejected.

Verify the boundary with ordinary fixtures

Create fixtures for an empty object, valid supported values, an unexpected field, a top-level array, malformed JSON, a string in place of an integer, an oversized body and excessive nesting. Confirm that accepted results contain only the contract's keys and rejected inputs do not partially update saved preferences.

Use these as application tests rather than uploading unknown samples to production. Include the migration reader/writer compatibility case and an interrupted job resume case. Keep logs to identifiers and outcomes; avoid recording entire user documents when those could contain personal data.

Finally, removing an unsafe parser does not patch the PHP runtime itself. Follow the runtime verification guide independently, and use bound SQL values when storing the validated result. Source behavior was checked on 22 October 2026; the parser is an original illustrative example.