Enforce HTTPS for credential-bearing provider health checks

[coderabbitai]

Summary

Require HTTPS before any provider health check sends an API key, bearer token, or other credential to a configured endpoint.

Azure OpenAI validation can accept an http:// api_base. The Azure lightweight health check then sends the submitted credential in request headers. An attacker on that network path can read or modify the credential.

Required changes

• In src/api/provider_validation.py, validate that Azure api_base uses the https scheme before _test_azure_lightweight_health constructs a credential-bearing request.
• Preserve the existing Azure OpenAI Service and Azure AI Foundry endpoint selection behavior.
• Review all similar provider health checks and credential-validation probes for endpoints that originate from configuration.
• For each equivalent request path, reject non-HTTPS endpoints before credentials are sent. Do not change intentionally local, credential-free health checks without a documented reason.

Affected areas

• src/api/provider_validation.py
• Other provider health-check and credential-validation modules identified by the audit
• Unit tests for validation and request construction

Acceptance criteria

• Azure OpenAI Service and Azure AI Foundry validation reject non-HTTPS api_base values before sending credentials.
• Existing valid HTTPS Azure endpoint behavior remains unchanged.
• The audit covers credential-bearing health checks that use configured endpoints.
• Tests prove that no credential-bearing request is made for rejected HTTP endpoints.
• Tests cover each additional affected provider path found by the audit.

References

• Pull request: fix: validate Azure OpenAI keys before saving Foundry endpoints #2373
• Review comment: fix: validate Azure OpenAI keys before saving Foundry endpoints #2373 (comment)
• Requested by: @edwinjosechittilappilly

[coderabbitai]

Preliminary static audit

Confirmed affected paths:

• src/api/provider_validation.py::_test_azure_lightweight_health sends an api-key or Authorization: Bearer header to a URL built from configured api_base without requiring https.
• src/api/provider_validation.py::_test_watsonx_completion_with_tools and src/api/provider_validation.py::_test_watsonx_embedding send an IBM bearer token to URLs built from configured endpoint without requiring https.

Not affected by this specific finding:

• The WatsonX lightweight check sends the API key only to the fixed HTTPS IBM IAM URL.
• The Ollama checks use a configurable endpoint but do not attach credentials in these functions.
• OpenAI and Anthropic checks use fixed HTTPS URLs.

The issue remains scoped to inspect provider enhancement checks and other configured credential-bearing request paths, then add HTTPS guards and tests for every confirmed path.

[coderabbitai]

Audit update: watsonx.ai on-prem enhancement

enhancements/providers/watsonx/onprem.py::lightweight_health_check is also in scope. It accepts configured api_base and performs an authenticated model-specification request with Authorization: ZenApiKey …. The implementation must be checked for a pre-request HTTPS requirement and covered by the remediation if it accepts HTTP URLs.

[coderabbitai]

Static audit result

The audit confirmed these credential-bearing configurable endpoint paths without a pre-request HTTPS requirement:

1. src/api/provider_validation.py::_test_azure_lightweight_health

   • Sends an Azure API key or Entra bearer token to a URL built from api_base.

2. src/api/provider_validation.py::_test_watsonx_completion_with_tools and src/api/provider_validation.py::_test_watsonx_embedding

   • Send an IBM bearer token to URLs built from configured endpoint.

3. enhancements/providers/watsonx/onprem.py::lightweight_health_check and enhancements/providers/watsonx/onprem.py::fetch_models

   • Send Authorization: ZenApiKey … to a URL built from configured api_base.

The following paths do not have this specific issue:

• OpenAI and Anthropic validation use fixed HTTPS vendor URLs.
• WatsonX lightweight validation sends its API key only to the fixed HTTPS IBM IAM URL.
• Ollama validation uses a configurable endpoint but does not attach credentials in these functions.

The implementation should reject non-HTTPS configured endpoints before it constructs each affected credential-bearing request. Add unit tests that verify rejection occurs before the HTTP client receives a request.