Security review: harden Ollama proxy URLs and add quiet logging mode

[whatnick]

Summary

I reviewed the Ollama proxy code and found a few concrete hardening opportunities. The current proxy already has meaningful protections in place (API-key auth, rate limiting, optional IP filtering, blocked endpoint support), so this is not a claim that it is openly exposed by default.

That said, there are still some security and operational risks worth addressing, especially around backend URL validation and overly verbose proxy failure logging.

Confirmed findings

1. Backend URL validation is too permissive

app/crud/server_crud.py currently accepts essentially any http or https backend URL as "safe":

• no private/reserved IP range checks
• no localhost / loopback rejection
• no DNS resolution checks to prevent internal-address targets
• no explicit allowlist mode for trusted upstreams

This looks like an admin-controlled SSRF / internal pivoting risk rather than a normal user-controlled open proxy, but it is still worth hardening.

2. Proxy failure logging is too verbose

app/api/v1/routes/proxy.py logs backend error bodies and request payload details during failures, including fields such as:

• backend error text
• model name
• options
• tools
• message counts

In practice this can leak sensitive prompt/tool metadata into logs, and backend error bodies may also contain secrets or private content.

3. A few defense-in-depth gaps remain

Possible follow-ups:

• enforce request body size limits
• better accounting / controls for long-lived streaming requests
• optional TLS-only backend enforcement for remote upstreams
• reduce or redact API key prefix logging

Suggested improvements

Add a quiet proxy logging mode

This would be the most useful immediate improvement.

Suggested behavior:

• add a setting such as proxy_log_mode = verbose | normal | quiet or a boolean like quiet_proxy_logs
• in quiet mode, do not log raw backend error bodies
• do not log tools, messages, or options payload contents
• only log minimal structured diagnostics such as:
  • request id
  • upstream server name
  • status code
  • path
  • model name only if explicitly safe / desired
• always redact secrets from headers and payloads before logging
• keep full payload diagnostics behind an explicit debug-only path

A good pattern would be:

• quiet: production-safe, minimal metadata only
• normal: concise diagnostics with redaction
• verbose: opt-in troubleshooting mode only

Harden backend URL validation

In app/crud/server_crud.py, consider:

• rejecting loopback, link-local, multicast, and RFC1918 private IP ranges
• resolving hostnames and rejecting those that map to private/internal addresses
• optionally allowing admins to enable an explicit backend host allowlist
• optionally requiring HTTPS for non-local backends

Tighten abuse controls

• add request size caps
• consider separate controls for concurrent/streaming requests
• review whether API key prefixes should appear in logs at all

Why this matters

The main concern is not that the proxy is unauthenticated — it is not. The concern is that in real deployments, logs often become a secondary data leak path, and permissive backend URL validation increases blast radius if admin access is abused or compromised.

Thanks for the project — the existing auth/rate-limit structure is already a strong base, and a quiet logging mode would make it much safer to run in production.