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
