JEP 415: Context-Specific Deserialization Filters

OwnerRoger Riggs
Componentcore-libs /
Discussioncore dash libs dash dev at openjdk dot java dot net
Relates toJEP 290: Filter Incoming Serialization Data
Reviewed byBrian Goetz, Chris Hegarty
Created2021/03/10 15:36
Updated2021/05/07 16:22


Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation.



Deserializing untrusted data is an inherently dangerous activity because the content of the incoming data stream determines the objects that are created, the values of their fields, and the references between them. In many typical uses the bytes in the stream are received from an unknown, untrusted, or unauthenticated client. By careful construction of the stream, an adversary can cause code in arbitrary classes to be executed with malicious intent. If object construction has side effects that change state or invoke other actions, those actions can compromise the integrity of application objects, library objects, and even the Java runtime. The key to disabling deserialization attacks is to prevent instances of arbitrary classes from being deserialized, thereby preventing the direct or indirect execution of their methods.

We introduced deserialization filters (JEP 290) in Java 9 to enable application and library code to validate incoming data streams before deserializing them. Such code supplies validation logic as a when it creates a deserialization stream (i.e., a

Relying on a stream's creator to explicitly request validation has several limitations. This approach does not scale, and makes it difficult to update filters after code has been shipped. It also cannot impose filtering on deserialization operations performed by third-party libraries in an application.

To address these limitations, JEP 290 also introduced a JVM-wide deserialization filter which can be set via an API, system properties, or security properties. This filter is static since it is specified exactly once, at startup. Experience with the static JVM-wide filter has revealed that it, too, has limitations, particularly in complex applications with layers of libraries and multiple execution contexts. Using the JVM-wide filter for every ObjectInputStream requires the filter to cover every execution context in the application, so the filter usually winds up being either too inclusive or too restrictive.

A better approach would be to configure per-stream filters in a way that does not require the participation of every stream creator.

To protect the JVM against deserialization vulnerabilities, application developers need a clear description of the objects that can be serialized or deserialized by each component or library. For each context and use case, developers should construct and apply an appropriate filter. For example, if the application uses a specific library to deserialize a particular cohort of objects then a filter for the relevant classes can be applied when calling the library. Creating an allow-list of classes, and rejecting everything else, gives protection against objects in a stream that are otherwise unknown or unexpected. Encapsulation or other natural application or library partitioning boundaries can be used to narrow the set of objects that are allowed or definitely not allowed. If it is not practical to have an allow-list then a reject-list should include classes, packages, and modules that are known not to occur in the stream or are known to be malicious.

An application’s developer is in the best position to understand the structure and operation of the application’s components. This enhancement enables the application developer to construct and apply filters to every deserialization operation.


As noted above, JEP 290 introduced both per-stream deserialization filters and a static JVM-wide filter. Whenever an ObjectInputStream is created, its per-stream filter is initialized to be the static JVM-wide filter. That per-stream filter can later be changed to a different filter, if desired.

Here we introduce a configurable JVM-wide filter factory. Whenever an ObjectInputStream is created, its per-stream filter is initialized to the value returned by invoking the static JVM-wide filter factory. Thus these filters are dynamic, unlike the single static JVM-wide deserialization filter. For backward compatibility, if a filter factory is not set then a built-in factory returns the static JVM-wide filter if one was configured.

The filter factory is used for every deserialization operation in the Java runtime, whether in application code, library code, or code in the JDK itself. The factory is specific to the application and should take into account every deserialization execution context within the application.

For simple cases, the filter factory can return a fixed filter for the entire application. For example, here is a filter that allows example classes, allows classes in the java.base module, and rejects all other classes:

var filter = ObjectInputFilter.Config.createFilter("example.*;java.base/*;!*")

In an application with multiple execution contexts, the filter factory can better protect individual contexts by providing a custom filter for each. When the stream is constructed, the filter factory can identify the execution context based upon the current thread-local state, hierarchy of callers, library, module, and class loader. At that point, a policy for creating or selecting filters can choose a specific filter or composition of filters based on the context.

If multiple filters are present then their results can be combined. A useful way to combine filters is to reject deserialization if any of the filters reject it, allow it if any filter allows it, and otherwise remain undecided.


We define two methods in the ObjectInputFilter.Config class to set and get the JVM-wide filter factory. The filter factory is a function with two arguments, a current filter and a next filter, and it returns a filter.

 * Return the JVM-wide deserialization filter factory.
 * @return the JVM-wide serialization filter factory; non-null
public static BiFunction<ObjectInputFilter, ObjectInputFilter, ObjectInputFilter>

 * Set the JVM-wide deserialization filter factory.
 * The filter factory is a function of two parameters, the current filter
 * and the next filter, that returns the filter to be used for the stream.
 * @param filterFactory the serialization filter factory to set as the
 * JVM-wide filter factory; not null
public static void setSerialFilterFactory(
            BiFunction<ObjectInputFilter, ObjectInputFilter, ObjectInputFilter>


This class shows how to filter to every deserialization operation that takes place in the current thread. It defines a thread-local variable to hold the per-thread filter, defines a filter factory to return that filter, configures the factory as the JVM-wide filter factory, and provides a utility function to run a Runnable in the context of a specific per-thread filter.

public class FilterInThread {

    // ThreadLocal to hold the serial filter to be applied (may be null)
    private final ThreadLocal<ObjectInputFilter> filterThreadLocal = new ThreadLocal<>();

     * Construct a FilterInThread.
    public FilterInThread() {}

     * The filter factory, which is invoked every time a new ObjectInputStream
     * is created.  If a per-stream filter is already set then it returns a
     * filter that combines the results of invoking each filter.
     * @param curr the current filter on the stream
     * @param next a per stream filter
     * @return the selected filter
    public ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter next) {
        var threadFilter = filterThreadLocal.get();
        return (curr == null)
                ? threadFilter
                : combineFilters(curr, next);

     * Apply the filter and invoke the runnable.
     * @param filter the serial filter to apply to every deserialization in the thread
     * @param runnable a Runnable to invoke
    public void doWithSerialFilter(ObjectInputFilter filter, Runnable runnable) {
        var prevFilter = filterThreadLocal.get();
        try {
        } finally {

If a stream-specific filter was already set with ObjectInputStream::setObjectFilter then the filter factory combines that filter with the next filter. If either filter rejects a class then that class is rejected. If either filter allows the class then that class is allowed. Otherwise, the result is undecided.

Here’s a simple example of using the FilterInThread class:

// Create a FilterInThread filter factory and set
    var filterInThread = new FilterInThread();

    // Create a filter to allow example.* classes and reject all others
    var filter = ObjectInputFilter.Config.createFilter("example.*;java.base/*;!*");
    filterInThread.doWithSerialFilter(filter, () -> {
          byte[] bytes = ...;
          var o = deserializeObject(bytes);


JEP 290 allows filters to be implemented as Java classes, thereby allowing complex logic and context awareness. Context-dependent stream-specific filters could be implemented through the use of a delegating filter that is set on every stream. To determine the filter for the specific stream, it would need to examine its caller and map the caller to a specific filter and then delegate to that filter. However, both code complexity and the overhead of determining the caller would impact performance on every invocation.