fix(security): honor endpoint overrides only in dev builds - #160
Conversation
RC_BASE_URL (and profile base_url), RC_PAYWALL_AI_BASE_URL, and RC_RICO_BASE_URL are now honored only in local dev builds. A shipped (release) binary always talks to the production RevenueCat endpoints, so a poisoned env or profile can't redirect a customer's credential elsewhere. New internal/buildinfo carries the dev/release signal from main's version. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
bugbot run |
customers simulate-purchase and offerings preview build an SDK service with rt.Config.BaseURL directly, bypassing the API() gate. Route them through a new Runtime.effectiveBaseURL() so a release binary never sends the public SDK key to a base_url override either. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 793103f. Configure here.
fire-at-will
left a comment
There was a problem hiding this comment.
I think there's one missed URL that needs protecting, otherwise looks good!
Slightly related, but can go in a different PR: do we maybe want to remove the --base-url flags in release builds for the same reason?
|
|
||
| import ( | ||
| "testing" | ||
|
|
There was a problem hiding this comment.
Nit: no need for this newline
| return fallback | ||
| } | ||
|
|
||
| // devEnvOrDefault honors an endpoint override env var only in dev builds; a |
There was a problem hiding this comment.
Is rico.go the best place for this function to live? It's a utility that is shared across many features and isn't rico-specific
There was a problem hiding this comment.
I think we should protect this call as well, otherwise oath credentials could be redirected here
Per review: also lock the OAuth base URL to production in release builds so auth can't be redirected, and move envOrDefault/devEnvOrDefault to env.go since they're shared, not rico-specific. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The API/service endpoints are overridable via env vars, which is only ever useful for local development against staging. In a shipped binary those overrides are just a way for a poisoned env or profile to send a customer's credential somewhere else. This locks release builds to production.
RC_BASE_URL+ profilebase_url,RC_PAYWALL_AI_BASE_URL,RC_RICO_BASE_URLare honored only in local dev builds.internal/buildinfocarries the dev/release signal frommain's version, so there's no goreleaser change.Dev workflow is unchanged: a local
go build/go runstill honors the overrides.Not touched:
RC_OAUTH_BASE_URLis the same class and could get the same treatment, but it's in the auth flow so I left it out of this pass, ask if you want it in.Note
High Risk
Changes authentication and API routing for all credential-bearing traffic; incorrect dev/release detection could break staging workflows or fail to block override attacks in release builds.
Overview
Release binaries no longer honor endpoint override env vars or profile
base_url, so credentials and API keys cannot be redirected via poisoned environment or config in shipped builds.A new
internal/buildinfopackage exposesIsDev()(version"dev"for localgo build/go run; release versions from ldflags).mainsetsbuildinfo.Versionat startup.devEnvOrDefaultandRuntime.effectiveBaseURL()apply overrides only whenIsDev()is true.Affected paths: API client base URL (
RC_BASE_URL/ profile), SDK calls (offerings, simulated purchase), Paywalls AI (RC_PAYWALL_AI_BASE_URL), Rico (RC_RICO_BASE_URL), and OAuth refresh host (RC_OAUTH_BASE_URL).envOrDefaultmoves toenv.go; tests coverIsDevanddevEnvOrDefault.Local dev behavior is unchanged when the binary is built with version
dev.Reviewed by Cursor Bugbot for commit d736bbd. Bugbot is set up for automated code reviews on this repo. Configure here.