How do Java object input filters (JEP 290) mitigate deserialization attacks, and what are their limits?

## The problem they solve Native Java deserialization rebuilds whatever classes the byte stream names, running their reconstruction logic before you can validate anything (see the 'why dangerous' question). The mitigation idea: **inspect the stream as it's being read and refuse to materialize disallowed classes**. That is exactly what an **object input filter** does. ## What a filter is Introduced in **Java 9 as JEP 290** (and present in 8u121+ via backport), a filter is an implementation of `ObjectInputFilter`. The JVM calls your filter's `checkInput(FilterInfo)` method: - **For every class** about to be resolved during deserialization (you get the `Class<?>` via `info.serialClass()`). - **For stream metrics**: current depth, number of references, stream size in bytes, array length being allocated. Your filter returns one of three statuses: - `Status.ALLOWED` — let it through. - `Status.REJECTED` — abort deserialization (throws `InvalidClassException`). - `Status.UNDECIDED` — defer to the next filter / default behavior. ## The allowlist pattern (the right way) The secure pattern is **deny by default**: explicitly ALLOW the handful of classes your endpoint legitimately expects, REJECT everything else. A pattern string makes this concise, e.g. `com.myapp.dto.*;java.util.ArrayList;!*` where the trailing `!*` rejects all not previously matched. This shrinks the attacker's reachable classes from 'everything on the classpath' to 'your few DTOs', which usually have no gadget potential. Alongside class checks, set numeric **resource limits** to stop denial-of-service payloads: `maxdepth` (nesting), `maxrefs` (object references), `maxbytes` (total stream size), `maxarray` (array element count). These stop 'billion laughs'-style streams that explode in memory before any class check matters. ## How to install one - **Per stream:** `ois.setObjectInputFilter(myFilter)` right after creating the `ObjectInputStream` — most targeted. - **Process-wide:** the JVM property/security property `jdk.serialFilter=...` applies a default filter to all streams. - **Java 17+ (JEP 415):** a **filter factory** — `ObjectInputFilter.Config.setSerialFilterFactory(...)` — lets you compose a context-specific filter per deserialization, so a library can layer its own filter on top of the application default. This fixed the gap where a single static filter couldn't adapt per call site. ## Limits and caveats (the senior nuance) 1. **An allowlisted class can still be a gadget.** If a class you must allow has a dangerous `readObject`, the filter won't save you — it only controls *which* classes, not what they do. 2. **Over-broad patterns reopen the hole.** Allowing a whole framework package (`org.somelib.**`) can readmit gadgets. Keep the list minimal. 3. **It is a mitigation, not elimination.** The authoritative guidance still says: **don't deserialize untrusted data at all**; prefer a data-only format (JSON/Protobuf). Filters are for cases where you're stuck with native serialization (legacy RMI/JMX, third-party blobs). 4. **No help for other formats.** A filter only governs `ObjectInputStream`; it does nothing for, say, an XML or JSON library configured to instantiate arbitrary types. 5. **You must know your legitimate set.** Maintaining an accurate allowlist requires understanding exactly what flows through each stream; a wrong list either breaks functionality or is too permissive. ## Bottom line Object input filters convert native deserialization from 'instantiate anything' to 'instantiate only what I named', plus enforce resource caps. That is a major risk reduction and the right tool when you cannot remove native serialization — but it sits *behind* the stronger architectural fix of not using native serialization on untrusted input.