I think this is a VERY feasible constraint that we could add to our V2 apis. I know less about the query apis. I don't think we should worry about the v1 APIs, they are what they are, and they should be retired.
One way to make that happen is to add that explicitly to https://github.com/apache/solr/pull/4826. As I'm going through V2 apis I am referencing this document. It has also found other gaps like not all V2 apis treat an error the same way. At some point we'll be able to review all our V2 apis for "Do they all do things the same way", like GETs don't mutate things. On Wed, Sep 16, 2026 at 9:55 AM Jan Høydahl <[email protected]> wrote: > 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 > <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 > <http://www.linkedin.com/in/davidwsmiley> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
