Jackson Deserialization Security

Key Concept: Deserialization Timing

Jackson transforms JSON text into Java objects during a single readValue() call. This transformation is not a simple data copy—Jackson interprets JSON structure, resolves types, handles special keys, and instantiates objects all within this operation.

JSON String → [Jackson Processing] → Java Object
                    ↑
            Attack surface here

Once deserialization completes, the resulting Java object contains no trace of how it was constructed. Any special JSON structures, unusual keys, or type directives that influenced object creation are no longer visible.

---

Why Post-Deserialization Validation Is Insufficient

Consider the lifecycle of a typical JSON endpoint:

1. HTTP request arrives with JSON body
2. Framework deserializes JSON → Java object (Jackson runs here)
3. Your code receives the Java object
4. Your code validates the object
5. Your code processes the object

Validation at step 4 examines the result of deserialization, not the process. Any malicious behavior triggered during step 2 has already executed. The Java object you're validating may appear completely normal while the attack has already succeeded.

This creates a fundamental blind spot: attacks that exploit Jackson's parsing behavior—rather than the final object state—cannot be detected by examining the deserialized object.

---

The Empty Key ("") Attack Vector

What Is It?

JSON permits empty strings as object keys:

{
  "name": "legitimate",
  "": "injected value"
}

This is valid JSON per RFC 8259. Jackson parses it without error.

Why Does It Matter?

Some applications and frameworks assign special meaning to empty keys:

• Injection points: Certain Jackson configurations use to set values on the root object or trigger special handling