chore: added openapi request adapting to ssl

[SamTV12345]

Closes #8129

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix OpenAPI server URL generation to respect request protocol

🐞 Bug fix 🧪 Tests 🕐 10-20 Minutes

AI Description

• Generate OpenAPI server URL using the incoming request protocol (supports reverse-proxy TLS).
• Export the server URL helper to make behavior testable.
• Add backend tests covering http vs https server URL emission.

Diagram

graph TD
  A["Express request"] --> B["openapi.ts"] --> C["generateServerForApiVersion"] --> D["OpenAPI server URL"]
  B --> E["OpenAPI definition"]
  F["Backend spec"] --> B

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Parse X-Forwarded-Proto directly

• ➕ Works even if Express trust proxy is not configured, as long as the header is set by the proxy
• ➖ Security footgun if untrusted clients can set X-Forwarded-Proto; requires careful proxy/trust configuration anyway

2. Keep settings.ssl as a fallback scheme source

• ➕ Maintains legacy behavior for deployments where req.protocol is unreliable
• ➖ Can still be wrong behind TLS-terminating reverse proxies, which is the core bug this PR addresses

Recommendation: Using req.protocol is the right default because it reflects the actual request scheme when Express is correctly configured (including reverse proxies). Consider documenting/ensuring Express 'trust proxy' is set in typical proxy deployments; otherwise, add a conservative fallback only if real-world reports show req.protocol is unreliable in supported setups.

Files changed (2) +27 / -1

Bug fix (1) +2 / -1

openapi.tsUse request protocol when generating OpenAPI server URL +2/-1

Use request protocol when generating OpenAPI server URL

• Changes server URL generation to use req.protocol instead of settings.ssl-derived scheme, making URLs accurate behind TLS-terminating reverse proxies. Also exports generateServerForApiVersion for direct reuse/testing.

src/node/hooks/express/openapi.ts

Tests (1) +25 / -0

openapi.tsAdd backend tests for OpenAPI server URL scheme +25/-0

Add backend tests for OpenAPI server URL scheme

• Adds a new backend spec that verifies generateServerForApiVersion emits http:// or https:// based on the request protocol and host header.

src/tests/backend/specs/openapi.ts

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

1. Proxy-spoofed OpenAPI scheme 🐞 Bug ⛨ Security

Description

generateServerForApiVersion() now uses req.protocol to select the scheme, which (when
settings.trustProxy is enabled) can be influenced by X-Forwarded-Proto and cause the generated
OpenAPI servers[0].url to advertise the wrong scheme under misconfigured/over-trusting proxy
setups. Prefer settings.publicURL when configured (operator-trusted), and otherwise harden the
fallback by whitelisting http/https and using Express’s host accessor (and optionally host
validation) instead of raw headers.

Code

src/node/hooks/express/openapi.ts[871]

+  url: `${req.protocol}://${req.headers.host}${apiRoot}`,

Evidence

The PR changes the scheme source from a server-side config (settings.ssl) to request-derived
req.protocol, while the app can be configured to trust proxy-provided X-Forwarded-* headers; the
codebase also documents and implements a safer pattern (publicURL preference + strict fallback)
for absolute URLs.

src/node/hooks/express/openapi.ts[868-872]
src/node/hooks/express/openapi.ts[693-707]
src/node/hooks/express.ts[157-165]
src/node/utils/Settings.ts[411-421]
src/node/utils/socialMeta.ts[139-155]
src/node/handler/RestAPI.ts[1446-1449]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`generateServerForApiVersion()` now builds the OpenAPI server URL using `req.protocol`, which becomes proxy-header-derived when `trustProxy` is enabled. This can cause the served OpenAPI document to advertise an incorrect scheme if proxy headers are missing/spoofed or the instance is reachable without a trusted proxy in front.

### Issue Context
The codebase already has an operator-trusted `settings.publicURL` intended to avoid client-controlled origin values, and `socialMeta.ts` demonstrates a hardened approach (prefer `publicURL`, otherwise validate host/proto).

### Fix Focus Areas
- src/node/hooks/express/openapi.ts[868-872]
- src/node/utils/Settings.ts[411-421]
- src/node/utils/socialMeta.ts[139-155]
- src/node/hooks/express.ts[157-165]

### Suggested fix
1) If `settings.publicURL` is set and valid, use it as the origin for `servers[0].url` (append `apiRoot`).
2) Else, keep the request-derived fallback but harden it:
  - Allow only `http` or `https` (fallback to `'http'` if unexpected).
  - Use `req.get('host')` instead of `req.headers.host` for consistency with other code paths.
  - (Optional but safer) validate/sanitize the host similarly to `socialMeta.ts`’s `sanitizeHost()` before emitting it into the OpenAPI document.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context

✅ Tickets: 🎫 OpenAPI servers URL uses http:// behind an HTTPS reverse proxy

Tip of the day

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Proxy-spoofed openapi scheme 🐞 Bug ⛨ Security

generateServerForApiVersion() now uses req.protocol to select the scheme, which (when
settings.trustProxy is enabled) can be influenced by X-Forwarded-Proto and cause the generated
OpenAPI servers[0].url to advertise the wrong scheme under misconfigured/over-trusting proxy
setups. Prefer settings.publicURL when configured (operator-trusted), and otherwise harden the
fallback by whitelisting http/https and using Express’s host accessor (and optionally host
validation) instead of raw headers.

Agent Prompt

### Issue description
`generateServerForApiVersion()` now builds the OpenAPI server URL using `req.protocol`, which becomes proxy-header-derived when `trustProxy` is enabled. This can cause the served OpenAPI document to advertise an incorrect scheme if proxy headers are missing/spoofed or the instance is reachable without a trusted proxy in front.

### Issue Context
The codebase already has an operator-trusted `settings.publicURL` intended to avoid client-controlled origin values, and `socialMeta.ts` demonstrates a hardened approach (prefer `publicURL`, otherwise validate host/proto).

### Fix Focus Areas
- src/node/hooks/express/openapi.ts[868-872]
- src/node/utils/Settings.ts[411-421]
- src/node/utils/socialMeta.ts[139-155]
- src/node/hooks/express.ts[157-165]

### Suggested fix
1) If `settings.publicURL` is set and valid, use it as the origin for `servers[0].url` (append `apiRoot`).
2) Else, keep the request-derived fallback but harden it:
   - Allow only `http` or `https` (fallback to `'http'` if unexpected).
   - Use `req.get('host')` instead of `req.headers.host` for consistency with other code paths.
   - (Optional but safer) validate/sanitize the host similarly to `socialMeta.ts`’s `sanitizeHost()` before emitting it into the OpenAPI document.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools