refactor: restrict OpenAPI $ref resolution to in-document pointers

[etairl]

Summary

• OpenAPIServiceToFunctions._parse_openapi_spec was calling jsonref.replace_refs with the library default loader, which dispatches arbitrary $ref URIs to the filesystem (file://) and the network (http(s)://).
• Pass an explicit loader that refuses any non-in-document $ref and set proxies=False so references must resolve eagerly during parsing.
• In-document JSON-pointer references (those starting with #) continue to work unchanged.

This is a defensive hardening change for OpenAPI specs whose contents are not fully trusted (e.g. fetched from third-party catalogs, generated by an LLM, or uploaded by end users). Specs that depend on external $ref resolution will now raise a RuntimeError instead of silently performing filesystem reads or outbound HTTP requests.

Test plan

• CI runs OpenAPIServiceToFunctions unit tests with the new loader.
• Manual: a spec containing an in-document $ref (e.g. #/components/schemas/Foo) still resolves correctly.
• Manual: a spec containing $ref: file:///etc/passwd or $ref: http://... raises and does not perform the I/O.

🤖 Generated with Claude Code

[vercel]

@etairl is attempting to deploy a commit to the deepset Team on Vercel.

A member of the Team first needs to authorize it.

[anakin87]

Hello, @etairl!

Could you better explain why this is needed?
Please also read our security policy before. If you have identified a vulnerability, please send us the details confidentially via email.

I also noticed that you opened multiple PRs. I'd suggest focusing on one at a time.

[etairl]

Hello, @etairl!

Could you better explain why this is needed? Please also read our security policy before. If you have identified a vulnerability, please send us the details confidentially via email.

I also noticed that you opened multiple PRs. I'd suggest focusing on one at a time.

Hi @anakin87,

Sorry about the spam (they've been sitting in my todos for a few days, created the PRs today in one batch). So on one hand this probably falls under out of scope category ("attacker-controlled input to Haystack is considered out of scope"). The reason it still should be a PR is that users expect "parse this spec" to just parse - not to read files or hit the network, so the default should be safer. This is security hardening rather than vulnerability patching.

[anakin87]

Thank you! I'll give this a better look later...

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
haystack/components/converters
openapi_functions.py					241, 268
Project Total

This report was generated by python-coverage-comment-action

[CLAassistant]

All committers have signed the CLA.

[etairl]

Thank you! I'll give this a better look later...

Thanks. Let me know of any required changes / questions.

[etairl]

Thank you! I'll give this a better look later...

@anakin87 Any update? Really looking to get the 3 bugs fixed as they were found as part of our dependency chain scanning.

[anakin87]

I looked better into this...

From our policy:

Haystack is a framework intended to run inside a trusted execution environment. It assumes that the application built with it has already validated and sanitized user-supplied input... Validation and sanitization of input [...] are the responsibility of the application, not Haystack.

In addition, $ref in OpenAPI can legitimately point to local files and remote URLs. Accepting this PR as-is would break those valid use cases.

Thanks for raising the concern, but for these reasons I'd suggest closing the PR.

[etairl]

I looked better into this...

From our policy:

Haystack is a framework intended to run inside a trusted execution environment. It assumes that the application built with it has already validated and sanitized user-supplied input... Validation and sanitization of input [...] are the responsibility of the application, not Haystack.

In addition, $ref in OpenAPI can legitimately point to local files and remote URLs. Accepting this PR as-is would break those valid use cases.

Thanks for raising the concern, but for these reasons I'd suggest closing the PR.

Thanks for pointing it out. I'll move input validation upstream to better handle all edge cases then. I'll close the other 2 PRs as well. I did stumble upon a non-security bug, I'll create a PR soon.