JSON Deserialization Type Confusion

Unrestricted polymorphic JSON deserialization can let an attacker influence which runtime type is instantiated, potentially reaching dangerous classes or behaviors. Java backends should constrain permitted types and treat serialized type metadata as untrusted input.

Deserialization converts JSON data into Java objects. Type confusion occurs when attacker-controlled data can influence the concrete class chosen during that process, especially when a framework supports polymorphic types through metadata such as a type identifier.

The security risk is not JSON itself; it is the combination of untrusted input and overly broad type resolution. If a deserializer accepts arbitrary class names or a large set of application classes, an attacker may select a type that has unsafe construction, property-setting, or subsequent behavior.

A safer design uses explicit DTOs and known target types whenever possible. When polymorphism is genuinely required, use a closed set of permitted subtypes, validate the discriminator, and avoid mechanisms that resolve arbitrary classes from input.

For Java applications, also review framework-specific polymorphic-deserialization settings, because the exact behavior depends on the serialization library and its configuration. Defense in depth includes input validation, minimizing dangerous classes on the classpath, and keeping dependencies patched.

Key points

• Treat type metadata in incoming JSON as untrusted input.
• Prefer concrete DTO types over unrestricted polymorphic deserialization.
• If polymorphism is necessary, allow only an explicit set of known subtypes.
• Do not resolve arbitrary Java class names supplied by a client.
• Review deserializer configuration and dependency versions for unsafe polymorphic features.

Interview questions

What is JSON deserialization type confusion?

It occurs when untrusted JSON can influence the concrete Java type created during deserialization. This becomes dangerous when the application accepts more types than the endpoint actually needs. An attacker may then reach unexpected classes or behaviors. The basic defense is to deserialize into a known DTO or a tightly controlled subtype hierarchy.

How would you secure polymorphic deserialization in a Java service?

I would first determine whether polymorphism is actually required and replace it with explicit DTOs when possible. If it is required, I would define a closed set of permitted subtypes and validate the discriminator against that set. I would avoid accepting arbitrary class names from the request. I would also review the serialization library's configuration and keep it current.

Why can unrestricted polymorphic deserialization become a security issue even when setters only assign fields?

Deserialization is not necessarily limited to passive data containers. The selected class may have constructors, property handling, lifecycle behavior, or interactions with other framework features that make the resulting object security-sensitive. A broad type universe therefore increases the reachable attack surface. The important boundary is preventing untrusted data from selecting unintended classes.

What is the difference between validating JSON structure and controlling polymorphic types?

Structural validation determines whether fields, types, and constraints match an expected data model. Type control determines which application classes are eligible to represent that data. A document can satisfy a structural schema while still causing an unsafe runtime type to be instantiated if the deserializer permits it. Therefore both data validation and explicit type constraints may be needed.

How would you investigate a suspected deserialization type-confusion vulnerability?

I would identify the deserialization entry point, determine the declared target type, and inspect how type metadata is interpreted. Then I would enumerate the classes that the configuration permits and check whether client input can select outside the intended domain. I would reproduce the behavior with benign test classes or controlled test fixtures rather than relying on assumptions about a particular exploit chain. Finally, I would verify the fix with regression tests and configuration checks.