Consider limiting total auto-grow work during Java form binding #13982

Just a reminder, not urgent and nothing really dangerous:

Play Java form binding limits individual auto-grown collection/array. This prevents requests such as:

items[999999].name=value

from forcing very large allocations.

However, this does not fully cover nested collection paths where each individual index is within the configured limit:

orders[255].lines[255].options[255].value=value

For a matching form model, binding may still auto-grow multiple nested collections and intermediate objects:

class OrderForm {
    public List<Order> orders;
}

class Order {
    public List<Line> lines;
}

class Line {
    public List<Option> options;
}

class Option {
    public String value;
}

Each individual index is below the default limit of 256, so the request is allowed, but the total amount of object/collection growth can multiply across path depth and submitted fields.

This is not exploitable for arbitrary form models: the submitted field path needs to match the application's form object structure. Still, nested collection-heavy forms such as orders, surveys, invoices, or configurable products could make binding allocate more objects than expected.

Possible follow-up options:

• Add a maximum nested binding path depth, for example play.forms.binding.maxNestedPathDepth.
• Add a per-bind auto-grow operation budget, for example play.forms.binding.maxAutoGrowOperations.
• Add tests that submit deeply nested indexed paths and verify Play returns normal form errors instead of excessive allocation, stack overflow, or uncaught binding exceptions.

A total auto-grow budget may be more robust than only a depth limit because it limits overall binding work regardless of the exact path shape.