Unsafe deserialization

What it means

Deserialization turns stored or transmitted data into application structures. Some object serializers can instantiate classes or invoke behavior during reconstruction, making untrusted input especially dangerous. Prefer simple data formats and explicitly supported types rather than restoring arbitrary executable object graphs.

A practical example

A service exchanges ordinary JSON records with a partner instead of accepting serialized runtime objects. It validates the expected fields and creates its own application objects, keeping the partner's data separate from type selection and execution behavior.

What to check

Inventory deserializers, review allowed types and library capabilities, and avoid native object restoration from untrusted sources. Authenticate data where appropriate, but still limit what reconstruction can do.

A common pitfall

Calling a format binary or internal does not establish trust. A signed object can also become dangerous if an attacker obtains signing access or the allowed behavior is too broad.

Think it through

Why prefer a data-only representation for a partner message?

Answer: It reduces the chance that parsing chooses executable classes or behavior rather than simply delivering expected values.

Data restoration can carry hidden behavior

A fictional fulfilment service receives shipment messages from a partner. The business requirement is simple: shipment identifier, address, and delivery preferences. A runtime object format may express much more than those values, including class identities and nested objects with behavior attached. Reconstructing that representation can therefore grant the sender influence over application execution.

Choosing JSON does not eliminate all parsing risks, but a deliberately restricted data model makes the contract easier to inspect. Parse the message into ordinary fields, reject unexpected structures where appropriate, and construct internal objects through the application's own logic. Do not let a field supplied by the partner select arbitrary runtime types.

Trust can change over time. Messages may pass through queues, caches, or archived files before being consumed. An internal queue is not sufficient evidence that every producer is trusted for every behavior the consumer can perform. Signing messages can establish a particular origin when implemented correctly, but the consumer still needs to limit what an authenticated sender is allowed to request.

Draw the reconstruction path

For a learning exercise, compare two fictional shipment contracts. One contains an explicit identifier and delivery fields; the other allows the sender to name the runtime class to instantiate. Draw which component chooses behavior in each design. Explain how malformed nesting or unusually large collections should be handled before expensive processing.

Review dependency updates and format migrations as security changes. A library upgrade may alter available classes or validation behavior, while an old worker may continue accepting a legacy object format. The practical goal is to reduce the reconstruction surface and demonstrate that accepted messages remain data. This is a stronger assurance than relying on a format being obscure, binary, or used only by an internal application.

Related concepts

• Input validation
• Software supply chain security
• Least privilege