What is insecure deserialization?
Serialization turns an object or data structure into a storable or transferable format. Deserialization turns it back into a usable object. Insecure deserialization happens when an application accepts serialized data from an untrusted source and deserializes it without enough validation, integrity checking, or safety controls.
Insecure deserialization is a vulnerability that happens when an application rebuilds objects or data structures from untrusted input without proper safeguards. A deserialization vulnerability can let an attacker tamper with application state, bypass controls, crash services, or in some cases achieve remote code execution. In short, the problem is not serialization itself. The risk appears when the application trusts serialized data it should treat as hostile.
What serialization and deserialization mean
Serialization is the process of converting data into a format that can be stored or transmitted. Deserialization is the reverse process: the application reconstructs that data into an object or structure it can use again.
This is common in:
- session handling
- API communication
- caching
- cookies
- message queues
- background job systems
- file import and export workflows
By itself, serialization is normal engineering practice. The danger appears when externally supplied data is treated like trusted internal state.
Why insecure deserialization is dangerous
A lot of people assume deserialization is just passive data parsing. In some languages and frameworks, that is not the full story.
During deserialization, the runtime may trigger:
- object creation
- property setters
- initialization routines
- implicit method calls
- class loading
- gadget chains already present in application libraries
That means an attacker may be able to do more than change a few values. They may be able to influence how the application behaves during the deserialization process itself.
Possible impacts include:
- data tampering
- authentication bypass
- privilege escalation
- denial of service
- remote code execution
For a related concept, see what is remote code execution.
Where insecure deserialization shows up
A deserialization vulnerability often appears when applications deserialize data from places such as:
- HTTP requests
- cookies
- API parameters
- hidden form fields
- uploaded files
- message brokers
- cached session objects
- internal service traffic
This matters because developers sometimes assume those sources are safe enough if they come from a user session or another internal service. That assumption is often wrong.
Common attack scenarios
Session or cookie tampering
Some applications store serialized session state on the client side. If that state is not strongly protected, an attacker may modify it before sending it back.
They may try to change fields such as:
- account ID
- user role
- feature flags
- expiration timestamps
- tenant identifiers
If the server trusts the modified object, the attacker may gain higher privileges or bypass application logic.
Unsafe API object handling
Modern applications and microservices exchange structured data constantly. If a backend service deserializes incoming objects too permissively, attackers may abuse that trust boundary.
This can affect:
- REST or RPC APIs
- queue consumers
- job processors
- backend integrations
- service-to-service messages
When teams think only about browser input and ignore backend object handling, insecure deserialization can go unnoticed.
Remote code execution through gadget chains
One of the highest-impact outcomes is remote code execution. In some ecosystems, attackers can craft a payload that abuses classes already present in the application or its dependencies.
Instead of injecting new code directly, they chain together existing behavior in unsafe ways. That is why insecure deserialization is closely associated with object injection and high-severity application exploits.
Why this vulnerability is hard to catch
Insecure deserialization is not always obvious during routine testing. The vulnerable behavior may depend on:
- specific frameworks
- hidden parsing paths
- internal-only endpoints
- a certain serialization format
- default library behavior
- available classes in the runtime environment
A normal UI test may never touch the vulnerable code path. That is why application security reviews need to look beyond visible forms and pages.
For a broader risk framework, see what is the owasp top 10.
How to reduce the risk
The safest approach is usually to avoid deserializing untrusted objects whenever possible. If that is not realistic, reduce exposure with layered controls.
Avoid native object deserialization when possible
If simple data structures are enough, prefer safer patterns over automatic rebuilding of complex objects from untrusted input.
Formats like JSON can be easier to reason about than native object serialization, though they are not automatically safe.
Validate input strictly
Treat serialized input as hostile. Only accept:
- expected fields
- expected types
- expected values
- expected structure
Reject extra properties, malformed content, and unexpected object types.
Protect integrity
If state must travel to the client and back, use strong integrity protection so users cannot alter it silently. Sensitive state should not be trusted just because it came from your own application earlier.
Restrict allowable classes
Where supported, use allowlists or safe deserialization modes to prevent arbitrary class instantiation and unsafe behaviors during deserialization.
Keep dependencies updated
Some exploitation paths rely on vulnerable libraries or known gadget chains in outdated dependencies. Dependency hygiene helps reduce the attack surface.
Monitor for suspicious parsing behavior
Useful signals include:
- unexpected serialized blobs in requests
- parsing or deserialization errors
- crashes tied to malformed input
- unusual object types being processed
- suspicious activity after state restoration
Common misconceptions
“It only matters if users upload files”
No. Insecure deserialization often happens in cookies, API bodies, tokens, and background messages, not just uploaded files.
“JSON is always safe”
Not automatically. JSON is simpler than many native serialization formats, but unsafe parsing, weak validation, and over-trusting client-controlled fields can still create serious problems.
“This is only a Java issue”
No. Java is often discussed because of well-known deserialization risks, but the broader problem exists across multiple languages and frameworks.
“Internal traffic is trusted traffic”
Not necessarily. Internal services can be compromised, spoofed, or misused. Modern architectures often have weaker internal trust boundaries than teams assume.
“Encryption alone solves it”
No. Encryption may hide the data, but it does not automatically make unsafe deserialization safe. Validation, integrity, and deserialization controls still matter.
Final takeaway
Insecure deserialization is dangerous because it turns untrusted data into application behavior. If your system rebuilds objects from user-controlled or externally supplied input, assume that input can be malicious. The best defense is to avoid unsafe deserialization patterns where possible, validate aggressively, restrict what can be rebuilt, and monitor how serialized data is handled throughout the application.
Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.