Fix Flowise 6602: add HTTP_ALLOW_LIST for trusted SSRF hosts#6627
Fix Flowise 6602: add HTTP_ALLOW_LIST for trusted SSRF hosts#6627laraib-W wants to merge 2 commits into
Conversation
…usted hosts Custom MCP servers reachable via Docker Compose service names (e.g. mcp-server) resolve into 172.16.0.0/12 and are rejected by checkDenyList. The only prior escape hatch was HTTP_SECURITY_CHECK=false, which disables SSRF protection globally. Introduces HTTP_ALLOW_LIST — a comma-separated list of hostnames whose deny-list check is skipped. Entries are exact, case-insensitive hostname matches (no wildcards). Applies to both checkDenyList and the pinned-agent resolveAndValidate path used by secureFetch / secureAxiosRequest, so redirect chains remain safe: a hop off an allowed host to an unrelated private IP is still blocked. Adds 13 tests covering the allow list, whitespace/case normalization, DNS-skip behavior in checkDenyList, and the direct-IP + hostname paths in resolveAndValidate via secureFetch. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces the HTTP_ALLOW_LIST environment variable, allowing specified hostnames to bypass SSRF protection checks and connect to trusted internal services. The changes include parsing logic, integration into the security check functions, comprehensive unit tests, and updated documentation. Feedback suggests enhancing the allowlist parsing logic to robustly handle ports and IPv6 brackets to prevent common configuration errors.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Users naturally copy the "host:port" or "[::1]" form from connection strings
into HTTP_ALLOW_LIST, but URL.hostname strips ports and brackets before the
allow list is checked, so those entries would silently never match.
Normalize entries in getHttpAllowList to match what the URL parser produces:
- "host:port" -> "host"
- "[::1]" -> "::1"
- "[::1]:8080" -> "::1"
- bare IPv6 (e.g. "fe80::1") is left as-is (guarded by ipaddr.isValid to
avoid truncating on ":" like the port-stripping branch would)
Adds 5 tests covering each normalized form and the bare-IPv6 non-mutation
case. Updates .env.example and CONTRIBUTING.md to document the accepted
formats.
Addresses review feedback on FlowiseAI#6627.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
1 participant
Closes #6602
Summary
HTTP_ALLOW_LISTenv var — comma-separated hostnames whose SSRF deny-list check is skipped172.16.0.0/12and are rejected bycheckDenyList; the only prior workaround wasHTTP_SECURITY_CHECK=false, which disables SSRF protection globallycheckDenyListand the pinned-agentresolveAndValidatepath used bysecureFetch/secureAxiosRequest, so redirect chains remain safe — a hop off an allowed host into an unrelated private IP is still blockedNaming note
Chose
HTTP_ALLOW_LISTover the reporter-suggestedMCP_ALLOW_LISTto mirror the existingHTTP_DENY_LISTnaming and cover every SSRF-guarded call site (not only MCP).Test plan
pnpm --filter flowise-components test -- httpSecurity— 79/79 pass, including 13 new tests for the allow listHTTP_ALLOW_LIST=<service-name>without settingHTTP_SECURITY_CHECK=false