bug: validate deprecated proxy route before forwarding - #1755
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6d412ab6c4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| * Support the /v1 proxy endpoint | ||
| */ | ||
| app.post('/v1/proxy/*', proxyHandler); | ||
| app.post('/v1/proxy/*', requestValidator, proxyHandler); |
There was a problem hiding this comment.
Preserve trusted config hosts on workerd
On workerd deployments, adding the full validator here makes deprecated-proxy requests using x-portkey-config reject explicitly trusted private hosts. The config refinement calls isValidCustomHost(customHost) without the Hono context (schema/config.ts:169-171), while Environment(undefined) returns {} outside Node (utils/env.ts:138-145), so the worker's TRUSTED_CUSTOM_HOSTS binding is ignored and the request receives a 400. The header form works because requestValidator passes c; config validation should likewise receive the request context before this route is subjected to it.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in eca1a73b. Config-level custom-host validation now receives the Hono request context, including recursive targets, so Workerd TRUSTED_CUSTOM_HOSTS bindings remain effective. The focused reproducer failed before the correction (expected 204, received 400) and the suite now passes 4/4; the same private config host without a trusted binding still returns 400.
Summary
This is the focused fix for the SSRF validator bypass reported in issue #1718.
The deprecated
POST /v1/proxy/*route invokedproxyHandlerwithoutrequestValidator, while the general/v1/*route already applied the validator. That allowedx-portkey-custom-hostto bypass the existing custom-host checks on the deprecated route.This patch:
requestValidatorbeforeproxyHandler;TRUSTED_CUSTOM_HOSTSbindings while still rejecting the same host when it is not trusted.No provider behavior, dependency, generated file, or unrelated route changes.
Verification
Passed:
npx jest src/index.test.ts --runInBand --no-cache— 4 tests passednpm run format:checknpx eslint src/index.ts src/index.test.ts src/middlewares/requestValidator/index.ts src/middlewares/requestValidator/schema/config.tsnpm run build— completed with the repository's existing Rollup/TypeScript warningsnpm run pre-push— build plus app-start smoke passedgit diff --checkThe Workerd regression test failed before the follow-up correction (
expected 204, received400) and passes afterward. The same private config host without a trusted binding remains rejected with400 Invalid config passed.The repository-wide
npm run test:gateway -- --runInBand --no-cachecommand remains red on currentmainfor unrelated baseline problems: missing unit-test module paths, absenttests/integration/src/handlers/.creds.json, and pre-existing TypeScript errors. It still completed 49 existing tests successfully, including the focused regression before the follow-up additions.Scope
This closes the disclosed route-level bypass; it is not a claim of complete SSRF resistance or an independent security audit.
Closes #1718