Black-box scanners rarely find insecure deserialization because proving it needs the right data format, a usable chain of code in the target's libraries, and often an out-of-band callback. A generic probe cannot guess those. Code and dependency analysis find the risky calls and libraries far more reliably.
What it is
Serialization turns an object into data that can be stored or sent. Deserialization rebuilds the object. The OWASP testing guide says insecure deserialization occurs when an application deserializes untrusted data without sufficiently verifying that it is valid, and that the most critical impact is remote code execution. It can also cause denial of service, authentication bypass and access control issues.
Think of a cookie that holds a serialized user object with an admin flag. If the server trusts it, changing one value changes who you are.
Why generic scanning struggles
The testing guide's own method shows how much knowledge is involved.
- Find the entry points. Serialized data may sit in cookies, hidden fields, API bodies, headers or uploaded files.
- Recognize the format. Java serialized data begins with the bytes AC ED 00 05, often shown as rO0 once base64 encoded. PHP serialization is readable text with markers for objects and arrays. Python pickle can be opaque binary or base64. .NET output from legacy formatters often begins with a recognizable base64 prefix. Some JSON libraries accept type metadata fields that choose which class to build.
- Pick a safe probe. The guide advises an out-of-band or benign crash probe, such as a payload that makes a DNS or HTTP callback to a server the tester controls, and says never to start with a destructive payload.
- Match a gadget chain. Many bugs need a sequence of existing code fragments in the app or its dependencies. The tester identifies libraries first, then generates a non-destructive confirmation payload for them.
Each step depends on the previous one. A scanner that does not recognize the format never reaches the probe, and one that cannot receive callbacks cannot confirm the result.
What each approach finds
| Approach | Strength | Gap |
|---|---|---|
| Black-box scan | Can spot recognizable serialized values in cookies and parameters | Rarely confirms exploitation without callbacks and library knowledge |
| Static code analysis | Finds calls that deserialize untrusted input | Cannot tell whether a gadget chain exists in a given deployment |
| Dependency scanning | Finds libraries with known deserialization advisories | Does not know if your code feeds them untrusted data |
| Manual testing | Can combine all of the above | Slow, needs expertise |
The strongest result comes from combining them: a dependency scan says which libraries are present and affected, code analysis shows whether untrusted data reaches the call, and a targeted manual test confirms.
How to reduce the risk
The OWASP Deserialization Cheat Sheet lists language-agnostic methods, including using alternative data formats and only deserializing signed data. It also describes keeping sensitive fields out of serialization, for example marking them transient in Java. In practice:
- Prefer plain data formats such as JSON with a fixed schema for anything untrusted.
- Never deserialize native object formats from users.
- Sign data you must round trip, and verify before parsing.
- Keep dependencies patched, since gadget chains often live in libraries.
- Remove legacy formatters that the vendor has marked obsolete.
Our posts on deserialization risks across Python, Java and .NET and how to review code that deserializes data go further.
Try it yourself
Click through it at your own pace, or open it full screen. See how a code scan points to the exact line where input reaches a risky call.
Quick check
Is JSON safe from deserialization attacks?
Plain JSON parsing into simple data is much safer than native object formats. Risk returns when a library lets the input choose the class to build. See our post is JSON safe from deserialization attacks.
What should I scan to find this class of bug?
Scan dependencies for affected libraries and your code for calls that deserialize untrusted data, then confirm findings by hand.
Safeguard runs dependency scanning with reachability analysis, which helps show whether a vulnerable library is actually called, and offers a free scan at gold.safeguard.sh/scan.
Sources
- OWASP WSTG: Insecure Deserialization
- OWASP Deserialization Cheat Sheet
- CWE-502: Deserialization of Untrusted Data
Last reviewed: 19 October 2026.
