Big +1 Some of these could even land in 10.x with a clear explanation why in upgrade notes.
And the whole V1 API legacy also allows mutation on get, should start deprecating those and eventually remove as their V2 couterpart gets stable. Don't need to graduate all V2 APIs in the same release. Jan > 16. sep. 2026 kl. 04:05 skrev David Smiley <[email protected]>: > > I have a wish-list I want to share for better security defaults. Perhaps > Solr 11 if not sooner. > > (A) HTTP GET is purely read-only. The request is retry-able. Under no > circumstances, not even some delegating request, should a GET ever result > in an index state mutation or a change to the cluster shape. For example a > GET to /solr/coll/stream (streaming expressions) should be forbidden from > using streaming expressions that update an index. > > Furthermore, some handlers (e.g. SearchHandler) may be written/configured > to enforce read-only, even if POST is used (e.g. due to big queries). I > want to configure /stream handler as read-only but cannot do so today. > > (B) A collection-scoped request is isolated/firewalled to that collection. > A request to /solr/foo/whatever can only interact with the "foo" collection > (or any of its cores), or, if it points to an alias for multiple > collections, it must be scoped to those collections. I understand we have > useful capabilities to break free, even to another cluster, but such > capabilities should be opt-in (i.e. an admin *must* _do something_ to allow > for that). The _something_ would be a solr.xml or sys-prop/env-var change, > NOT a configset change (at least not only). > > As we accomplish such aspirational goals, we then update the threat model > https://github.com/apache/solr/blob/main/THREAT_MODEL.md > > The above two rules would allow an org to configure simple GET-only proxies > at certain paths and easily reason about what they are exposing. > > I'm tempted to create 11.0 blocker umbrella issues for both. > > > > > > > It's pretty remarkable what we allow, especially via streaming > expressions. A request to /solr/fooCollection/stream is in no way scoped > to that collection. to use expressions that (A) write data (e.g. vi > to (A) mutate data (e.g. "update", expressions that communicate with > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
