You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by David Smiley <ds...@apache.org> on 2026/09/16 02:05:06 UTC
Aspirational goals for better default security
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
Re: Aspirational goals for better default security
Posted by David Smiley <ds...@apache.org>.
AH; I forgot about QUERY -- +1 to that! A good newdev ticket.
On Thu, Sep 24, 2026 at 9:04 AM Jason Gerlowski <ge...@gmail.com>
wrote:
> +1 to the general "aspirations" from David's initial email.
>
> On the v1 vs. v2 question, I think it's a matter of level-of-effort.
> If there's bandwidth and energy to bring these ideals back to v1 and
> we find creative backwards-compatible ways to do it - that's great!
> But we're describing a decent amount of work here, and we as a
> community aren't flush with bandwidth, so it may make sense to
> prioritize the APIs we see sticking around longer-term.
>
> > 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.
>
> Have y'all seen the new "QUERY" Http method? I stumbled on this (I
> think Ken L shared it somewhere) earlier this year, but it seems
> tailor-made for replacing our "POST" usage in SearchHandler:
> https://www.rfc-editor.org/info/rfc10008/
>
> Best,
>
> Jason
>
> On Wed, Sep 16, 2026 at 11:30 AM David Smiley <ds...@apache.org> wrote:
> >
> > I don't see these goals as specifically linked to v2. Someone sloppily
> > using GET inappropriately today (which happens all over the place, I'm
> > aware) can and should stop. It's not unreasonable to fail such requests
> > (GET requests performing modifications) in a minor release for better
> > security. The underlying infra shouldn't have to do with v1 vs v2. I
> > propose that the "read-only" constraint should be a first class property
> of
> > the SolrQueryRequest. Any place where a new SQR is created must be
> updated
> > carefully to propagate this—perhaps as a mandatory constructor argument.
> > Same for the collection/alias scoping. It shouldn't matter if
> > V2HttpSolrCall or HttpSolrCall builds the SQR. We'll need to ensure that
> > both pieces info ride on federated requests somehow (e.g. shard fan-out
> is
> > always POST but ought to articulate read-only somehow). Maybe HTTP
> headers.
> >
> > On Wed, Sep 16, 2026 at 10:56 AM Eric Pugh <
> epugh@opensourceconnections.com>
> > wrote:
> >
> > > 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 <ja...@apache.org> 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 <ds...@apache.org>:
> > > > >
> > > > > 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: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > >
> > >
> > > 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.
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Aspirational goals for better default security
Posted by Jason Gerlowski <ge...@gmail.com>.
+1 to the general "aspirations" from David's initial email.
On the v1 vs. v2 question, I think it's a matter of level-of-effort.
If there's bandwidth and energy to bring these ideals back to v1 and
we find creative backwards-compatible ways to do it - that's great!
But we're describing a decent amount of work here, and we as a
community aren't flush with bandwidth, so it may make sense to
prioritize the APIs we see sticking around longer-term.
> 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.
Have y'all seen the new "QUERY" Http method? I stumbled on this (I
think Ken L shared it somewhere) earlier this year, but it seems
tailor-made for replacing our "POST" usage in SearchHandler:
https://www.rfc-editor.org/info/rfc10008/
Best,
Jason
On Wed, Sep 16, 2026 at 11:30 AM David Smiley <ds...@apache.org> wrote:
>
> I don't see these goals as specifically linked to v2. Someone sloppily
> using GET inappropriately today (which happens all over the place, I'm
> aware) can and should stop. It's not unreasonable to fail such requests
> (GET requests performing modifications) in a minor release for better
> security. The underlying infra shouldn't have to do with v1 vs v2. I
> propose that the "read-only" constraint should be a first class property of
> the SolrQueryRequest. Any place where a new SQR is created must be updated
> carefully to propagate this—perhaps as a mandatory constructor argument.
> Same for the collection/alias scoping. It shouldn't matter if
> V2HttpSolrCall or HttpSolrCall builds the SQR. We'll need to ensure that
> both pieces info ride on federated requests somehow (e.g. shard fan-out is
> always POST but ought to articulate read-only somehow). Maybe HTTP headers.
>
> On Wed, Sep 16, 2026 at 10:56 AM Eric Pugh <ep...@opensourceconnections.com>
> wrote:
>
> > 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 <ja...@apache.org> 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 <ds...@apache.org>:
> > > >
> > > > 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: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> >
> > 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.
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Aspirational goals for better default security
Posted by David Smiley <ds...@apache.org>.
I don't see these goals as specifically linked to v2. Someone sloppily
using GET inappropriately today (which happens all over the place, I'm
aware) can and should stop. It's not unreasonable to fail such requests
(GET requests performing modifications) in a minor release for better
security. The underlying infra shouldn't have to do with v1 vs v2. I
propose that the "read-only" constraint should be a first class property of
the SolrQueryRequest. Any place where a new SQR is created must be updated
carefully to propagate this—perhaps as a mandatory constructor argument.
Same for the collection/alias scoping. It shouldn't matter if
V2HttpSolrCall or HttpSolrCall builds the SQR. We'll need to ensure that
both pieces info ride on federated requests somehow (e.g. shard fan-out is
always POST but ought to articulate read-only somehow). Maybe HTTP headers.
On Wed, Sep 16, 2026 at 10:56 AM Eric Pugh <ep...@opensourceconnections.com>
wrote:
> 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 <ja...@apache.org> 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 <ds...@apache.org>:
> > >
> > > 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: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
> 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.
>
Re: Aspirational goals for better default security
Posted by Eric Pugh <ep...@opensourceconnections.com>.
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 <ja...@apache.org> 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 <ds...@apache.org>:
> >
> > 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: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
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.
Re: Aspirational goals for better default security
Posted by Jan Høydahl <ja...@apache.org>.
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 <ds...@apache.org>:
>
> 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: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org