fix(core): enforce https on custom proxy/cdnproxy urls - #1300
Merged
Conversation
abueide
approved these changes
Aug 25, 2026
abueide
added a commit
that referenced
this pull request
Sep 1, 2026
Root cause of the 83/90 CI failures, and it was never a CI problem. #1300 (fix(core): enforce https on custom proxy/cdnproxy urls) landed on master after this branch was cut. getURL now throws on any http:// proxy unless allowInsecureProxy is set. sdk-e2e-tests hands the SDK its mock server as http://localhost:PORT, so both getEndpoint and getEndpointForSettings threw, hit their catch blocks, and fell back to the production Segment endpoints. Events left for the real api.segment.io, the mock server received nothing, and all 83 assertions failed as "expected [] to have a length of N" - one fault, not 83. Worth noting: this means CI runs have been sending test events to production Segment under throwaway test-<uuid> write keys. Every earlier local run passed only because this checkout predated #1300 - which is also why "works locally, fails in CI" looked like an environment difference and sent the first diagnostic after an IPv6 red herring. This branch now merges origin/master, so local runs exercise the same code CI does. The CLI is a test driver talking to a local mock, so it opts in explicitly rather than weakening the check. The warning #1300 emits alongside the flag is appropriate and left in place. Verified against current master with the enforcement present: with the flag: 88 passed | 2 skipped (13 files) without the flag: 0 requests reach the mock, same fallback in stderr Also removes the temporary diagnostic and its workflow step, having served its purpose. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
abueide
added a commit
that referenced
this pull request
Sep 1, 2026
Same fault as the e2e-cli one, in the mobile example app, and currently
masked by stale build artifacts.
buildClient('yup') is the default client, so useProxy is always true and
proxy/cdnProxy are set to http://localhost:9091/v1 (iOS) and
http://10.0.2.2:9091/v1 (Android) - the Detox mock server. Since #1300
getURL rejects insecure proxy URLs, so both would throw, fall back to the
production Segment endpoints, and leave the mock server with nothing to
assert on. Confirmed by calling the current getURL directly on both URLs:
http://localhost:9091/v1 -> throws "Insecure HTTP proxy URL rejected..."
http://10.0.2.2:9091/v1 -> throws "Insecure HTTP proxy URL rejected..."
The reason the Detox suites still pass today is that the installed
artifacts predate the change - the APK was built Jul 24 and the .app Jul 27,
while #1300 landed Aug 25. Every mobile run so far, including the 8/8 iOS
and 7/8 Android results, exercised a month-old SDK. The next rebuild would
have turned both suites red for a reason that has nothing to do with
whatever change triggered the rebuild.
NOT VERIFIED END TO END. Confirming it requires rebuilding the app, and the
build needs the devbox-provided toolchain: gradle reads ANDROID_COMPILE_SDK
/ ANDROID_NDK_VERSION etc. from the environment the plugin sets up, and the
globally installed NDK 23.1.7779620 is too old for RN 0.84 (folly's
F14Table.h needs C++20 std::regular). Rebuild inside devbox and re-run both
suites to close this out.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task:
Enforce HTTPS on custom proxy/cdnProxy URLs (write key sent over cleartext) ·
packages/core/src/util.ts:261-288(getURL/validateURL), consumed atSegmentDestination.ts:388andanalytics.ts:383.getURL()only upgrades tohttps://when the host has no scheme. An explicithttp://proxy/cdnProxy is preserved, andvalidateURL's regex allowshttps?://.uploadEvents()then POSTs{ batch, sentAt, writeKey }— write key and all event PII — in cleartext to that host, exposed to on-path attackers. Default hosts are https, so this only bites with a misconfigured custom proxy, but the SDK permits the downgrade silently.http://proxy/cdnProxy unless an explicitallowInsecureProxyopt-in is set. At minimum log a loud warning. Document that the write key + PII travel in the body.What changes are done:
-
[packages/core/src/util.ts]— getURL now throws on http:// unless allowInsecure=true is passed; logs a console.warn when the opt-in is used-
[packages/core/src/types.ts]— added allowInsecureProxy?: boolean to Config with a doc comment explaining the risk-
[packages/core/src/analytics.ts]— passes this.config.allowInsecureProxy to getURL for the CDN proxy path-
[packages/core/src/plugins/SegmentDestination.ts]— passes config?.allowInsecureProxy to getURL for the upload proxy path-
[packages/core/src/tests/util.test.ts]— two new tests covering the rejection and opt-in paths