You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "potiuk (via GitHub)" <gi...@apache.org> on 2026/07/14 12:08:43 UTC
[PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
potiuk opened a new pull request, #160:
URL: https://github.com/apache/solr-mcp/pull/160
**This is a proposal for the Solr PMC to review — please correct, reject, or discuss as needed.** The maintainers are the decision-makers; nothing here is a requirement.
This adds a **v0 draft threat model** (`THREAT_MODEL.md`) for the Solr MCP Server plus the conventional discoverability wiring — a `## Security` section in the existing `AGENTS.md` pointing at a new `SECURITY.md`, which points at `THREAT_MODEL.md` — so an automated agentic security scanner can mechanically find the model.
**Context.** The ASF Security team is preparing Apache Solr's repositories for an automated agentic security scan. Discoverability (the scanner following `AGENTS.md → SECURITY.md → model`) is the one hard gate — without it a scan can't run. The Solr *search server* (`apache/solr`) already has its model merged; this PR is the equivalent for the **MCP server**, whose surface is different again (a Spring AI Model Context Protocol bridge exposing Solr operations as tools to AI clients). The model cross-references `apache/solr`'s `THREAT_MODEL.md` for the backend-Solr side.
**This is a v0 draft — mostly `*(inferred)*`.** The Security team drafted it from the repo's public artefacts (the `docs/security/` STDIO + HTTP pages, the tool/service classes, `SolrConfig`, the security config classes, `XmlDocumentCreator`) using the [`threat-model-producer`](https://gist.github.com/potiuk/da14a826283038ddfe38cc9fe6310573) rubric. Every claim carries a provenance tag; every `*(inferred)*` tag routes to a matching question in **§14 Open questions**. Easiest review is to **react** to §14 (one-line confirm / correct / strike per question); we fold your answers in and the tags become `*(maintainer)*`.
The draft leans on your existing `docs/security/*.md` work — it credits the secured-by-default HTTP posture (OAuth2 + JWT audience binding + restrictive CORS), the STDIO OS-user trust model, the XXE-hardened XML indexing, and the read+additive-only tool set as **provided** properties, and centers the genuinely MCP-specific risks (prompt injection / tool-poisoning via returned Solr content; single shared backend credential with no per-caller authz; the `SOLR_URL`-is-deployer-config-not-tool-input invariant) as the disclaimed properties and open questions.
**Scope note:** solr-mcp was one of the repos flagged for scope confirmation in the scan enrollment. If the PMC would rather **not** include it this cycle, close the PR and we'll drop it. If you'd rather own the model yourselves, close it and we'll wait.
Questions / pushback welcome — happy to adjust anything to match project conventions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "epugh (via GitHub)" <gi...@apache.org>.
epugh commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5050216347
hey @potiuk and @adityamparikh so going through the answers, I am onboard with all the §14 answers that @adityamparikh has provided. I'm not a security guy, so I'm going off my best effort, and honestly, @adityamparikh is a lot closer to this code so I trust him.
@potiuk I'll let you make the next set of changes... Let me know when we are ready to merge this!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5438257299
Thanks @adityamparikh — that re-verification against `main` rather than
against the review thread is the right way to check a document like this,
and the JWT audience point is exactly the claim I'd have wanted someone to
go and confirm independently.
Nothing outstanding from our side. To answer @epugh's question directly:
**yes, this is ready to merge whenever a committer wants to click it.**
No blockers, no pending changes, and it merges clean.
On the `stateless` observation — agreed it's orthogonal to the transport
name and not a correction, so I'd rather not churn the PR for it. If it
turns out to matter, the sharper framing for a follow-up is that
`spring.ai.mcp.server.protocol=stateless` disables the per-request context
features (sampling, progress, server→client logging), which is a property
worth stating in §5a only if something downstream starts relying on them
being available. Happy to open that as a separate PR after this lands if
you want it captured.
One practical note on why it's worth landing rather than leaving open:
merging this puts `AGENTS.md` → `SECURITY.md` → `THREAT_MODEL.md` on the
default branch, which is the chain a scan agent follows to find a project's
model. `apache/solr-mcp` is the one repo in Solr's requested scope that
isn't discoverable yet, so this PR is the last thing between it and
eligibility for a scan. No urgency attached — just so the merge isn't
sitting there looking purely cosmetic.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5142019487
No need for a cross-ref for my sake. This should be quite obvious now. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5124588773
Thanks @potiuk for embedding the open Q issue and @epugh for weighing in and supporting the idea for 1.0. I filed an open issue #169 to formally document that we do not support multi tenancy deployments. This is a conservative stance to take in a v1.0 releaes, and I think not a controversial decision that will likely be opposed by other PMC members.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "adityamparikh (via GitHub)" <gi...@apache.org>.
adityamparikh commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5341525826
@epugh — re "should we merge this then?": I re-verified the document's checkable claims against `main` (`a84033b`) rather than against the earlier review thread. **Everything I can mechanically check is accurate, and it merges clean. No blockers from me.**
What I verified this pass:
**Config surface (§5a, §13).** Every environment variable the model names exists in the code exactly as spelled — `HTTP_SECURITY_ENABLED`, `MCP_CORS_ALLOWED_ORIGINS`, `OAUTH2_ISSUER_URI`, `PROFILES`, `SOLR_URL`, `SOLR_USERNAME`, `SOLR_PASSWORD`. Worth calling out because our own docs have repeatedly invented a `SECURITY_ENABLED` toggle with the wrong default; this document does not.
**"HTTP is secured by default" (§5a).** Matches `application-http.properties`:
```properties
http.security.enabled=${HTTP_SECURITY_ENABLED:true}
```
Default `true`, so the secured filter chain is the default posture, as the §5a table states.
**"`@PreAuthorize` on every tool" (§8.1).** Confirmed — 11 `@McpTool` methods across `CollectionService`, `IndexingService`, `SchemaService` and `SearchService`, and 26 `@PreAuthorize` annotations covering those tools plus the prompt/resource methods. No unguarded tool.
**JWT audience validation (§8.1, §9).** This is the claim I most expected to be wrong, because stock Spring Security validates `iss`/`exp` but *not* `aud`. It is correct — we explicitly opt in:
```java
.authorizationServer(issuerUrl).resourcePath("/mcp").validateAudienceClaim(true)
```
So "validates sig/iss/exp/aud" is accurate rather than aspirational.
**Provenance (§1).** "No *(inferred)* claims remain" holds — all 13 previously-inferred tags now read *(maintainer)*.
**Tenancy open question.** Resolved in the meantime: #169 landed as `a57f4d9`, documenting the single-tenant deployment model. §2/§10/§11a already carry that decision, so nothing here goes stale on merge.
One non-blocking note for future readers, not a change request: the overview describes HTTP as "streamable-HTTP", which is the right MCP transport name, but `application-http.properties` also sets `spring.ai.mcp.server.protocol=stateless`. Those are orthogonal (transport type vs. mode within it), so the text is not wrong — it just does not mention that per-request context features (sampling, progress, server→client logging) are off in our configuration. Fine as a follow-up if the scan ever cares.
LGTM from my side.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5111442898
Hi, I am not deeply familiar withe the low-level code in mcp-server, but I get the design decision of a fixed solr credential, and that the http-mode is secured with oauth2 by default.
This should likely be elevated to a dev-list discussion, but IMO it will be a can of worms to try to do fine-grained auth/authz on the mcp-server level and support true multi-tenant users.
I'm tempted to document in the project and threat model that the only supported and recommended mode for using solr-mcp is for each user to have their own instance of solr-mcp with their own designated personal SOLR_USER/SOLR_PASSWORD pair - which maps to a user/roles on the solr-backend side that decides what that user is allowed to do.
Such a clarification would make a 1:1 connection to the user writing the prompt and the permission that user is given in solr backend. This means that one person might need to setup two instances of solr-mcp, one for normal work and an elevated instance of admin work. If we document such a constraint, we can effectively forward any permission vulnerability report to the solr server itself, since the mcp user is just using solr-mcp as any other solr client that acts on her behalf. I.e. if a vuln. report comes in that user Y can do destructive action Z, that will always be due to mis-configured solr-server.
In a later version of solr-mcp we can try to aim for multi tenancy or forwarding credentials.
WDYT @epugh - are we ready to decide here or should we bring it up as a topic on the dev list first?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5117127746
Thanks both — pushed as `3084fe5`.
**@epugh** — this is the next set of changes you asked for. Aditya's answers are now folded into the document body rather than sitting in the review thread, so the claims read as the project's own position instead of our reading of it. Concretely:
- All 13 inline `*(inferred)*` provenance tags are now `*(maintainer)*`. No inferred claims remain.
- The precision points Aditya added are in the body where a triager will actually hit them — §5a now records that the HTTP transport is stateless and that `/mcp` is `permitAll()` with auth enforced by `@PreAuthorize("isAuthenticated()")` on every tool, resource, prompt and completion handler; §6 records that `collection` can't escape the fixed `SOLR_URL` host and that there's no server-side bound on `rows`/facets/body size; §9 records that no `q`/`fq` escaping is performed, citing #122 and #127 as the closed-by-design precedent.
- §11a gained two entries. One is the `permitAll()` reading — that's precisely the false positive an automated scanner will file, so it's now pre-empted, with the carve-out that an entry point found *without* the annotation would be a real finding.
- Admin-tool exposure and read-only-subset proposals route to #66, in both §9 and the §13 disposition table.
- §14 is rewritten as maintainer answers, attributed and dated.
The `SECURITY.md` disclosure address was already aligned to `security@solr.apache.org` back in `440d5d4`, so that item from your list was closed.
**@janhoy** — thanks, that's a useful framing and I've recorded it as `Q-tenancy` in §14, deliberately **not** written into §2/§8/§10. You asked whether to decide here or take it to the dev list, so it isn't ours to settle — putting it in as a maintainer position while that's live would misrepresent the project.
Two observations for when you do pick it up. First, it strengthens §10 (downstream responsibilities) rather than changing any §8 claim: the server gains no new property, it makes an existing operator assumption explicit and testable — which is the useful kind of threat-model statement, because it converts "user Y did destructive thing Z" from an ambiguous report into a Solr-side misconfiguration by construction. Second, it interacts with #66: if per-tool roles land server-side, one-instance-per-user becomes a recommendation rather than the only supported mode, which is a §12 model-changing event.
Happy to draft the §2/§10/§11a wording once you've decided, or to leave it entirely with the project. Either way it doesn't hold anything up — an undecided question recorded as undecided is a perfectly good state for a threat model to be in.
From our side this is ready to merge.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "epugh (via GitHub)" <gi...@apache.org>.
epugh commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5334129074
Catching up on things... SO, should we merge this then?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "epugh (via GitHub)" <gi...@apache.org>.
epugh merged PR #160:
URL: https://github.com/apache/solr-mcp/pull/160
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5016592330
@adityamparikh — thank you, this is exactly the review that turns an inferred model into a maintainer-owned one. Every §14 answer confirmed, with several precision points we couldn't have gotten from public artefacts alone.
On our side:
1. I'll push the **disclosure-address fix** now — aligning `SECURITY.md` to `security@solr.apache.org` to match `THREAT_MODEL.md` §1. Good catch.
2. I'll **hold the fold-in** of your answers into `THREAT_MODEL.md` — flipping every `*(inferred)*` to `*(maintainer)*` and incorporating your precision notes (the streamable-HTTP **stateless** posture; the `permitAll()` + per-entry-point `@PreAuthorize("isAuthenticated()")` enforcement model; routing read-only / per-tool-role hardening to #66; and the "query-parser expressiveness and resource bounds are Solr's responsibility" position from the #122/#127 closures) — until @epugh / @janhoy have had the review you asked for. Once they weigh in I'll push the revision so it's merge-ready.
The enrollment and merge call is the Solr PMC's, as you note. Thanks again — this is the model working as intended: we draft, you correct, the project owns it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "adityamparikh (via GitHub)" <gi...@apache.org>.
adityamparikh commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-4996028470
@epugh @janhoy — could you review the maintainer answers above (per-question §14 responses + support for including solr-mcp in this scan cycle) before they get folded into the threat model?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "epugh (via GitHub)" <gi...@apache.org>.
epugh commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5118970021
> Hi, I am not deeply familiar withe the low-level code in mcp-server, but I get the design decision of a fixed solr credential, and that the http-mode is secured with oauth2 by default.
>
> This should likely be elevated to a dev-list discussion, but IMO it will be a can of worms to try to do fine-grained auth/authz on the mcp-server level and support true multi-tenant users.
>
> I'm tempted to document in the project and threat model that the only supported and recommended mode for using [solr-mcp](https://issues.apache.org/jira/browse/SOLR-mcp) is for each user to have their own instance of [solr-mcp](https://issues.apache.org/jira/browse/SOLR-mcp) with their own designated personal SOLR_USER/SOLR_PASSWORD pair - which maps to a user/roles on the [solr-backend](https://issues.apache.org/jira/browse/SOLR-backend) side that decides what that user is allowed to do.
>
> Such a clarification would make a 1:1 connection to the user writing the prompt and the permission that user is given in solr backend. This means that one person might need to setup two instances of [solr-mcp](https://issues.apache.org/jira/browse/SOLR-mcp), one for normal work and an elevated instance of admin work. If we document such a constraint, we can effectively forward any permission vulnerability report to the solr server itself, since the mcp user is just using [solr-mcp](https://issues.apache.org/jira/browse/SOLR-mcp) as any other solr client that acts on her behalf. I.e. if a vuln. report comes in that user Y can do destructive action Z, that will always be due to mis-configured [solr-server](https://issues.apache.org/jira/browse/SOLR-server).
>
> In a later version of [solr-mcp](https://issues.apache.org/jira/browse/SOLR-mcp) we can try to aim for multi tenancy or forwarding credentials.
>
> WDYT @epugh - are we ready to decide here or should we bring it up as a topic on the dev list first?
Our goal is to get a 1.0 out that meets the needs of our users. I think a simple approach that says "means that one person might need to setup two instances" is perfectly good for our 1.0 release. Let's not gold plate this thing until we know we have active user base!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5133628275
Thanks @janhoy — #169 is a good place to land it formally.
Worth noting the model in this PR already carries the decision rather
than leaving it open: §2 states one-instance-per-user as the supported
1.0 deployment mode, §10 puts the per-user credential on the operator,
§11a makes "user Y can perform destructive action Z" a non-finding (with
the carve-out that an identity the operator never configured is still
`VALID`), and §12 records that multi-tenancy or credential forwarding
would retire the mode. §14 Wave 5 logs it as answered, citing your
reasoning and Eric's scoping call.
So #169 and this PR agree — #169 just gives it a tracker item to
reference. Happy to add a cross-reference to #169 in §14 if you'd like
the provenance pinned to an issue rather than a thread; one line, say the
word. Otherwise this is ready to merge from my side.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md) [solr-mcp]
Posted by "adityamparikh (via GitHub)" <gi...@apache.org>.
adityamparikh commented on PR #160:
URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-4995864931
Thanks @potiuk and the ASF Security team — this is a remarkably accurate read of the
codebase from public artefacts. I've verified every §14 question against the source;
answers below, one per question. Overall: **I support including solr-mcp in this scan
cycle** and merging this PR once the answers are folded in and the one inconsistency
noted at the end is fixed. (Final call on merge/enrollment belongs to the PMC, of
course — flagging on the dev list.)
## Wave 1 — scope and trust posture
**Q-clienttrust — confirmed.** The client's identity is operator-authorized (the
operator chose to connect it), but every tool argument it emits is treated as
untrusted data — the server validates nothing about the natural language upstream of
it. Model-side defenses (approval UX, content filtering) belong to the client and
operator.
**Q-transport / Q-httpsec — confirmed.** Both dispositions are right:
`HTTP_SECURITY_ENABLED=false` on a network deployment is
`OUT-OF-MODEL: non-default-build`, and unauthenticated STDIO is
`KNOWN-NON-FINDING`. Two precision notes you may want to fold in:
- The HTTP transport is streamable HTTP running in **stateless** mode
(`spring.ai.mcp.server.protocol=stateless`), which also means no
sampling/progress/elicitation and no per-request context features.
- `/mcp` is `permitAll()` at the filter-chain level; authentication is enforced by
`@PreAuthorize("isAuthenticated()")` on every MCP entry point — all 11 tools, both
resources, all prompts and completion handlers carry it (the
spring-ai-community/mcp-security "secured tools" pattern).
**Q-adminexposure — confirmed as the intended v0 posture, and yes, a
`VALID-HARDENING` target.** There is no per-tool or per-collection gate today, and
that's deliberate for v0 — but fine-grained per-tool authorization is already on the
roadmap as #66 ("Have specific security roles"). Reports proposing a read-only tool
subset or per-tool roles should be triaged `VALID-HARDENING` and routed to that
issue.
## Wave 2 — data-flow and injection
**Q-promptinj — confirmed: disclaimed, `BY-DESIGN`.** The server returns Solr
content verbatim to the model and cannot meaningfully sanitise it; the defense
belongs to the client (approval UX — which the server supports by advertising honest
`readOnlyHint`/`destructiveHint` annotations) and to the operator (don't back the
server with a Solr writable by untrusted parties, per §10/§11). Reports of injected
instructions in returned Solr content should be closed `BY-DESIGN`.
**Q-queryinj — confirmed.** The server performs **no escaping** of `q`/`fq` — full
Solr query-parser expressiveness is the feature, and its blast radius is governed by
the backend Solr's posture (route such reports to apache/solr's model). This is a
documented maintainer position: PRs #122 and #127, which added server-side query
escaping/validation, were closed with the rationale that such hardening belongs in
Solr/SolrJ rather than this bridge.
**Q-collection — confirmed: no host escape.** The base URL is fixed at startup from
`SOLR_URL` and the `collection` argument is used only as a path segment against it.
The server does not validate the collection string beyond that; what a given path
reaches *within* the configured Solr host is governed by that Solr's own
authorization — the backend's boundary (apache/solr's model), not this server's,
consistent with the #122/#127 position above.
## Wave 3 — backend, resources, telemetry
**Q-backendcreds — confirmed.** A single static credential (or none), read once from
`SOLR_USERNAME`/`SOLR_PASSWORD` at startup and applied only when both are set; no
per-caller credential and no identity passthrough. (If #66 lands, authorization
becomes finer-grained *server-side*; the backend Solr credential would remain
shared.)
**Q-resource — confirmed.** No server-side cap on `rows`, facet cardinality, or
indexing-body size; bounds are the backend Solr's. Also a documented decision — PR
#127 (pagination/validation bounds) was closed for the same "Solr is responsible for
security" reason.
**Q-sideeffects / Q-otel — confirmed.** The side-effect inventory is complete:
outbound SolrJ connection (always), servlet listener (HTTP mode only), OTLP export
(when configured). Securing OTLP and TLS is operator infrastructure. No child
processes, no file reads from tool input. (`docker compose` autostart exists only in
http-profile `bootRun` local dev.)
## Wave 4 — meta / ownership
**Q-disclosure — `security@solr.apache.org`,** the Solr PMC's channel, same as
apache/solr. One fix needed in this PR: `SECURITY.md` currently says
`security@apache.org` while `THREAT_MODEL.md` §1 says `security@solr.apache.org` —
please align `SECURITY.md` to the Solr channel. (PMC to confirm routing.)
**Q-ownership — confirmed.** `THREAT_MODEL.md` as the canonical scanner-facing
model, `docs/security/*.md` remaining the operator-facing source of truth, with the
cross-references as proposed in §15. That matches how the existing docs are written.
---
**Summary of requested changes before merge:** align the disclosure address in
`SECURITY.md` to `security@solr.apache.org`. Everything else can be folded in from
the answers above, flipping the `*(inferred)*` tags to `*(maintainer)*`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org