AI-Generated Insecure Deserialization Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits code that deserializes data from outside the process. The goal is to stop a generated integration, cache layer, or file-import feature from shipping a native deserialization call against untrusted input, where simply parsing a crafted payload — before any application logic runs — can trigger denial-of-service or remote code execution.

This is a review policy, not a deserialization tutorial. It tells reviewers what must be true about a generated change's deserialization API choice and trust boundary before the change is safe to merge.

Review Inputs

Collect enough context to know what is being deserialized and where it came from.

• Every deserialization call the change adds or edits, and the exact API used (pickle.loads, yaml.load, ObjectInputStream#readObject, unserialize(), JSON.parse, a framework's model-binding layer, etc.).
• Where the serialized data originates: a request body, an uploaded file, a cache/queue message, a cookie, or a response from another internal or external service.
• Whether that source is fully trusted (only ever written by this application's own trusted code) or can be influenced by a user or another party.
• Whether an integrity check (signature/MAC) exists, and whether it runs before or after the deserialization call.

Format And API Rules

• Prefer JSON (or a YAML loader explicitly restricted to safe types) for any data that crosses a trust boundary; reserve native/full-featured serialization formats for data that never leaves fully trusted, internal control.
• Flag pickle.load/pickle.loads (Python), non-safe YAML loading (PyYAML without an explicit safe loader), ObjectInputStream#readObject on Serializable data (Java), unserialize() (PHP), and Marshal.load (Ruby) whenever the input isn't fully trusted — these formats can reconstruct arbitrary objects, including ones whose construction or destruction has side effects, by design.
• Confirm the deserialization target type is explicit and narrow (a known DTO/schema) rather than "whatever the stream says," even when using a nominally safer format like JSON, so unexpected fields or types can't silently reach application logic that assumes a specific shape.
• Do not treat a library's default constructor/loader as safe without checking; defaults have changed between major versions of common libraries, and the safe option is often the one that must be explicitly chosen.

Trust Boundary And Defense Rules

• When a native/full-featured format truly cannot be avoided, require a class/type allowlist so only explicitly approved types can be constructed during deserialization (Java: override resolveClass(); Python: restrict pickle's globals; equivalent mechanisms exist for other languages).
• Require an integrity check (a signature or MAC) that is verified before the deserialization call runs, for any serialized blob a client, cookie, cache, or other tamperable location could have modified — a check that runs on the already-deserialized object is too late.
• Treat any object round-tripped through the client (a serialized session, a "state" blob in a hidden field or cookie) as untrusted on the way back in, even if your own server produced it originally, unless it's signed or encrypted with a key the client never has.
• Mark sensitive fields that should never be (de)serialized or exposed (credentials, internal tokens, computed/derived values) with the language's exclusion mechanism (for example Java's transient) instead of relying on convention.

Merge Blockers

Block merge when any of these is true.

• Untrusted input (request body, upload, cache/queue message, cookie, cross-service response) reaches pickle, unsafe YAML loading, Java ObjectInputStream#readObject, PHP unserialize(), or an equivalent native deserializer with no allowlist or integrity check.
• A native format is used for a trust-boundary-crossing payload when a safe data-interchange format (JSON, restricted YAML) would work instead, with no documented reason.
• An integrity check exists but runs after deserialization rather than gating the deserialization call itself.
• A client-tamperable serialized blob (cookie, hidden field, cache entry a user can influence) is deserialized without a signature/MAC verified first.
• Sensitive fields on a serializable object are exposed with no exclusion mechanism applied.

Review Checklist

• {"task": "Deserialization calls identified", "description": "Every deserialization call in the change is identified along with its exact API and data source"}
• {"task": "Trust boundary assessed", "description": "Each data source is classified as trusted-internal or potentially attacker-influenced"}
• {"task": "Safe format preferred", "description": "Untrusted data uses JSON or an explicitly restricted YAML loader rather than a native full-featured format"}
• {"task": "Allowlist when native is required", "description": "Any unavoidable native-format deserialization of untrusted data is constrained by a class/type allowlist"}
• {"task": "Integrity check gates deserialization", "description": "Signature/MAC verification happens before the deserialization call, not after"}
• {"task": "Sensitive fields excluded", "description": "Fields that must not be exposed or attacker-set during (de)serialization use the language's exclusion mechanism"}

AI Review Rules

AI assistants can write and review deserialization code, but they should show their evidence.

• Ask the assistant to list every deserialization call in the change, the exact API, and the trust level of its input source.
• Require the assistant to justify any native/full-featured deserialization API used on data that isn't fully trusted-internal.
• Have the assistant confirm whether an integrity check exists and exactly where it runs relative to the deserialization call.
• Do not let the assistant claim a deserialization call is safe only because "it's from our own database/cache" without confirming nothing user-influenced ever writes to that store.
• Re-run review after any change to serialization formats, trust boundaries, or shared (de)serialization helper functions.

Troubleshooting

• Switching from pickle/native serialization to JSON breaks a custom type (datetime, a domain object with methods): implement explicit encode/decode functions for that type rather than reverting to a native format for convenience.
• A class allowlist rejects a legitimate internal type: add that specific type to the allowlist deliberately and re-test, rather than disabling the allowlist.
• An integrity check breaks a legitimate client round-trip: the client needs to receive and echo back the actual signed/encrypted blob, not a reconstructed copy — check that the signing key and the verification key match and that the payload isn't being rebuilt client-side.
• Tests only cover well-formed payloads: add a test asserting that a malformed or unauthorized-type payload is rejected before any object construction happens, not just that valid payloads succeed.

Duplicate And History Check

Before adding a new deserialization call, confirm the codebase does not already have a shared safe-deserialization helper (a wrapper enforcing a safe loader, an allowlist, or signature verification) for this data type. A generated change that adds a new native deserialization call next to an existing safe helper should be treated as suspicious — check whether the existing mechanism was simply not reused before introducing a second, possibly unsafe one.

Reference

Sources

• OWASP Deserialization Cheat Sheet
• CWE-502: Deserialization of Untrusted Data
• OWASP Top 10 2021 — A08: Software and Data Integrity Failures
• Python pickle documentation — Restricting Globals

• Source repositorygithub.com 2026-07-16T13:01:56+00:00
• Documentationcheatsheetseries.owasp.org
• Submitted by lourincedaging0-commits2026-07-15