Applications constantly turn bytes into useful values. A request body becomes a set of fields, a cached value becomes a record, or a message from a queue becomes a command. This conversion is called deserialization when the bytes represent a previously encoded data structure.
The security problem begins when deserialization does more than recover inert data. Some serialization systems can reconstruct application-specific object types or trigger behavior while rebuilding an object graph. If an attacker can influence that serialized input, the parser may be asked to create types or invoke mechanisms that the application never intended to expose at that boundary.
The consequence can be much more serious than receiving a malformed field. Depending on the serialization mechanism and the types available to it, unsafe deserialization can turn untrusted data into privileged application behavior.
This article develops a defensive mental model for deserialization. You will learn where the trust boundary sits, why a simple data format changes the risk, why parsing and validation are separate steps, and how to decide when a richer serialization mechanism is justified.
Think of deserialization as reconstruction under authority
A parser runs with the authority of the process that called it. It can allocate memory, create values, and sometimes interact with application types. The input, however, may come from a much less trusted source.
Consider a service that receives a message from outside its trust boundary:
external sender
|
v
serialized bytes
|
v
application parser
|
v
application objectsThe key question is not merely, “Can the bytes be decoded?” It is:
What is the decoder allowed to construct or cause while interpreting those bytes?
A decoder that only produces strings, numbers, booleans, lists, and maps has a narrower effect than a mechanism that can select arbitrary application classes and reconstruct their internal state. The second design gives the input more influence over what the process creates.
This is a trust-boundary problem because data controlled on one side can affect behavior on the more privileged side.
Separate inert data from executable behavior
The safest general mental model is to make serialized input describe data, not behavior.
Suppose an application needs to receive a password-reset request from an internal queue. A deliberately simple representation might be:
{
"account_id": "acct_4821",
"requested_at": "2026-09-04T02:15:00Z"
}Parsing this JSON should produce ordinary data values. The application then decides what those values mean and what operations are permitted.
The important property is not that JSON is automatically trustworthy. It is not. The useful property is that a conventional JSON data model does not require the sender to name arbitrary application classes in order to express these two fields.
Compare that with a hypothetical object-oriented serialization format that can say, in effect, “reconstruct an instance of this application type with this internal state.” If the decoder accepts type choices from an untrusted sender, the input controls a larger part of object construction.
Reducing that expressive power reduces the attack surface. It does not eliminate the need to validate the resulting data.
Parsing success is not validation
A common mistake is to treat successful decoding as evidence that the input is acceptable.
These are different questions:
- Parsing: Is the input structurally valid for the data format?
- Validation: Are the decoded values allowed for this application operation?
The example reset request may be valid JSON while still being invalid for the application. The account_id may not exist. The timestamp may be too old for the workflow. An unexpected field may indicate that the sender and receiver disagree about the message contract.
A defensive flow therefore has two explicit stages:
untrusted bytes
|
v
parse into a narrow data model
|
v
validate fields and invariants
|
v
perform an authorized operationEach stage answers a different security question. The parser limits what representation is accepted. Validation limits what values and combinations are meaningful. Authorization decides whether the requested operation may occur in the current security context.
Do not collapse those decisions into one “deserialization succeeded” check.
Prefer an explicit schema at untrusted boundaries
When input crosses a trust boundary, define the smallest data shape that the receiver actually needs.
For the reset message, the receiver might require exactly two fields with specific meanings:
account_id non-empty identifier in the expected format
requested_at timestamp that can be parsed and satisfies freshness rulesThe exact validation rules depend on the application. The important design choice is that the receiver owns the contract. It does not let the sender choose arbitrary runtime types merely because those types exist in the receiver’s process.
Schema-based formats can help make this boundary explicit. So can ordinary application code that decodes into a small dedicated data-transfer structure. The format matters less than the property you are trying to preserve: untrusted input should have a narrow, understandable mapping into application data.
For evolving protocols, decide how unknown fields and versions are handled. Rejecting every unknown field can expose compatibility problems early, but it can also make gradual upgrades harder. Ignoring unknown fields can support forward compatibility, but only if ignored data cannot silently change a security decision elsewhere. Choose deliberately and test mixed-version behavior.
Avoid polymorphic type selection from untrusted input
Some serialization libraries support polymorphism: encoded data can indicate which subtype should be reconstructed. This can be convenient when trusted components exchange complex object graphs.
At an untrusted boundary, unrestricted type selection is dangerous because the sender gains influence over which code paths participate in reconstruction.
If a protocol genuinely needs multiple message types, prefer a closed protocol-level discriminator rather than a general runtime type name. For example:
{
"kind": "password_reset_requested",
"account_id": "acct_4821"
}The receiver can map the small set of allowed kind values to its own handlers. An unknown value is rejected or handled according to the protocol’s versioning rules.
This is an allowlist at the protocol level. The sender chooses among operations that the protocol intentionally exposes, not among every constructible type available in the process.
An allowlist must remain narrow to be useful. Automatically adding every new application type to it recreates the original problem under a different name.
Do not confuse authenticity with safe interpretation
A message signature or message authentication code can establish that data came from a party holding the relevant key and that the protected bytes were not modified after authentication. That is valuable, but it answers a different question from whether deserialization is safe.
If every holder of the signing key is fully trusted to select every constructible type, authenticated serialization may fit the threat model. In many systems, that assumption is too broad. A compromised producer, an overly privileged integration, or a leaked signing credential can still produce authentic but dangerous input.
Treat authenticity and interpretation as separate controls:
- authentication answers who was authorized to produce the message under the keying model;
- parsing determines which representation the receiver accepts;
- validation determines whether the values satisfy the receiver’s rules;
- authorization determines whether the resulting operation is permitted.
Defense in depth is useful when a message can cause sensitive state changes. Authenticating a message is not a reason to give its contents unnecessary construction power.
Consider denial of service as part of the parser boundary
Even an inert data format can consume excessive resources. Deep nesting, very large collections, oversized strings, or expensive validation can exhaust memory or CPU before business logic rejects the request.
The relevant limits depend on the protocol and platform, so there is no universal safe number. Set bounds that follow legitimate use: maximum message size, sensible collection lengths, nesting limits where the parser supports them, and time or resource controls appropriate to the processing environment.
Apply coarse limits as early as practical. Rejecting an oversized message before building a large in-memory structure is usually cheaper than validating it after full reconstruction.
These controls reduce availability risk. They do not address unsafe object construction, so they complement rather than replace a narrow deserialization model.
Be careful with trusted storage and caches
It is tempting to classify data as trusted merely because it comes from a database, cache, local file, or internal queue. That conclusion is only valid if the entire path that can write the serialized value is inside the same trust boundary.
Ask where the bytes originally came from and who can change them.
For example, an application may store a serialized preference object in a database after receiving it from a client. Reading the value back later does not make the original client input trusted. Likewise, a shared cache writable by several services may cross more trust boundaries than its network location suggests.
If a rich serialization mechanism is necessary for internal state, restrict who can write that state, separate it from externally supplied serialized blobs, and keep the decoder’s permitted types as narrow as the design allows.
Verify the boundary with negative tests
A deserialization control is useful only if the implementation actually rejects inputs outside its intended model.
Tests should cover the boundary conditions that matter to the design. For a schema-driven message, verify that malformed structures fail, required fields are enforced, disallowed message kinds are rejected, size limits work, and invalid field combinations do not reach sensitive operations.
If the library supports type metadata, add a test showing that unapproved runtime types cannot be selected from input. This catches a dangerous class of regressions where a configuration change silently enables broader polymorphic decoding.
Also test the expected failure behavior. A rejected message should not partially update security-sensitive state before validation finishes. Logs should contain enough context to diagnose repeated failures without recording secrets or entire sensitive payloads.
Know what this control does not solve
Narrow deserialization reduces the risk that untrusted bytes can directly influence privileged object construction. It also makes the accepted input model easier to reason about and test.
It does not make valid data benign. A correctly parsed request can still ask for an unauthorized operation. Business-logic validation and authorization remain necessary.
It also does not protect a process that is already compromised. If an attacker can change the receiver’s code or parser configuration, they may be able to remove the restrictions. Protecting deployment integrity and limiting process privileges address different parts of that threat.
Finally, replacing a rich object format with a simpler format can require explicit mapping code and protocol-version handling. That is real engineering work. At a boundary exposed to less-trusted input, the extra explicitness is often valuable because it makes authority visible instead of hiding it inside object reconstruction.
Choose the narrowest mechanism that fits the boundary
For ordinary external requests, webhooks, queue messages, and other data-oriented interfaces, prefer formats and decoders that reconstruct a small inert data model. Define the accepted fields, validate their meaning, bound resource use, and authorize the resulting operation separately.
A richer object-serialization mechanism can be reasonable when both producer and consumer are inside a tightly controlled trust boundary and its operational benefits justify the added coupling. Even there, avoid assuming that “internal” means permanently trusted. Document who can write the serialized data and what happens if one producer is compromised.
The practical rule is simple: do not give serialized input more construction authority than the protocol requires. Treat deserialization as a trust boundary, keep the data model narrow, and let application code make the security-sensitive decisions explicitly.