Unauthenticated Stripe pass-through routes

[nathanclevenger]

Code-read on 2026-09-10 against f303cc8 (local) / b23b7bc (origin/main); the finding is the same on both. No requests were sent to the deployed worker. Full note: dot-do/apis docs/research/payments-do-auth-check.md.

Finding

Every REST route in src/index.ts except POST /webhooks calls getStripe().<resource>.<op>() with no check of who is calling. fetch (src/index.ts:623-652) goes matchRoute → handler → Stripe; there is no middleware, header inspection, or allowlist in between. The only 401 the worker can emit is Stripe rejecting the platform key (:116-124). src/env.d.ts:16-34 declares no caller-side secret or JWKS, so there is no auth mechanism even in configuration. The worker is routed publicly at payments.do/* (wrangler.jsonc:12-17), and the header comment's intent ("REST API for service binding consumers", :4) is not enforced.

getConnectOptions (:144-158) forwards Stripe-Account from the request header, or stripeAccount from the body, verbatim — so an unauthenticated caller can act as the platform on any connected account. The StripeDO rate limiter and method whitelist in src/stripe.ts are not wired (no durable_objects binding, never imported).

Routes

route	auth	Stripe op	money-moving?	reads customer data?	public?
POST /customers (:251)	none	customers.create	no	writes PII	yes
GET /customers/:id (:258)	none	customers.retrieve	no	yes	yes
PATCH /customers/:id (:264)	none	customers.update (body pass-through)	indirectly	writes PII	yes
POST /subscriptions (:273)	none	subscriptions.create	yes	—	yes
GET /subscriptions/:id (:280)	none	subscriptions.retrieve	no	yes	yes
DELETE /subscriptions/:id (:286)	none	subscriptions.cancel	yes	—	yes
PATCH /subscriptions/:id (:292)	none	subscriptions.update (body pass-through)	yes	—	yes
POST /subscriptions/:id/pause / resume (:300, :313)	none	subscriptions.update	yes	—	yes
POST /charges (:327)	none	charges.create	yes	—	yes
GET /charges/:id (:341)	none	charges.retrieve	no	yes (card last4, billing details)	yes
POST /invoices (:349)	none	invoices.create	yes	—	yes
GET /invoices/:id (:356)	none	invoices.retrieve	no	yes	yes
POST /invoices/:id/finalize / void (:362, :368)	none	finalizeInvoice / voidInvoice	yes	—	yes
POST /products, PATCH /products/:id (:376, :389)	none	products.create/update	catalog write	—	yes
POST /prices (:398)	none	prices.create	catalog write	—	yes
GET /products/:id, GET /prices/:id (:383, :405)	none	retrieve	no	no	yes
POST /refunds (:413)	none	refunds.create	yes (outbound)	—	yes
POST /import (:422-469)	none	lists ALL customers, subscriptions, products, prices, invoices on the platform account; emits to EVENTS under a caller-chosen ns (:424)	no	yes, in bulk	yes
GET /checkout (:477)	none (public buyer front by design; amount never from the query string)	checkout.sessions.create	session only	no	yes, intended
POST /webhooks (:520)	Stripe-Signature via constructEvent (:521-538)	event processing	no	no	yes, intended
unmatched paths (:641-650)	none	intended capnweb RPC over the whole Stripe SDK; dead under rpc.do@0.2.4 (RPC() is a client factory, .fetch → transport.call on the Stripe object → TypeError → 500)	—	—	returns 500

Recommended fix

Preferred (ax ADR 0023 §2): require a short-lived id.org.ai-issued JWT with aud=payments.do (RFC 8707) on every route except /, /checkout and /webhooks, verified against id.org.ai's JWKS pinned in deploy config. Derive tenant and the permitted Stripe-Account from the token's claims, never from the request header or body.

Smallest safe interim change: a PUBLIC_PATHS = ['/', '/checkout', '/webhooks'] allowlist at src/index.ts:629 (before matchRoute) that answers 404 for every other path unless the request arrived over a service binding; delete POST /import and the RPC fallback (:81-89, :641-650); drop the Stripe-Account/stripeAccount pivot from unauthenticated input. Service-binding-only exposure of the pass-through routes matches the stated intent (CLAUDE.md:21-26); /checkout and /webhooks must stay on the public hostname, so the route itself cannot simply be removed.

[nathanclevenger]

Fix prepared, not merged: #3 — bearer gate (PAYMENTS_API_TOKEN) ahead of matchRoute, allowlist exactly POST /webhooks + GET /checkout, fails closed when the secret is unset, Connect pivot gated. Merging does not deploy (manual pnpm deploy). Rollout order and the two headless.ly consumer call sites that must add the header are in the PR body.

[nathanclevenger]

PR #3 is merged to main (squash 3d46ad3) after independent adversarial review — but it is NOT deployed. Merging does not deploy (CI runs typecheck + tests only; deploy is the manual pnpm deploy).

Review verified: tsc --noEmit clean, 171/171 tests pass locally; the new test/auth-gate.test.ts fails 5/9 against the previous main (gate absent), and a 33-case bypass probe (method/path case, trailing slash, // prefix, HEAD/OPTIONS, unmatched → RPC fallback, stripeAccount body field, Stripe-Account on /webhooks, malformed/short/long/empty bearers, empty-string and unset secret, non-ASCII token) answered 401 on every gated variant without reaching the Stripe SDK. The gate runs before matchRoute in the only fetch branch, so nothing reaches Stripe or the RPC fallback without the bearer except exactly POST /webhooks (still Stripe-Signature verified, unchanged) and GET /checkout (which never reads Stripe-Account).

Rollout order (from the PR body) — do not deploy before step 1

1. Create the secret on this worker: wrangler secret put PAYMENTS_API_TOKEN (generate e.g. openssl rand -base64 32).
2. Update the two consumers to send Authorization: Bearer <same value> and give each its own copy of the secret (wrangler secret put PAYMENTS_API_TOKEN in each consumer's directory). Deploy the consumers — they keep working against the current unauthenticated worker, since it ignores the header.
   • headless.ly apps/db (db-headless-ly): apps/db/src/routes/integrations.ts:113 (fetchWithRetry, covers :149, :179, :247, :313), plus direct calls at :464 and :529; env type at :28.
   • headless.ly .do/api: .do/api/src/index.ts:383 — replace the verbatim forward of end-user headers with an explicit Authorization: Bearer ${c.env.PAYMENTS_API_TOKEN} (that call also targets /api/:id, which matches no payments.do route — separate fix).
3. Deploy this worker: pnpm deploy from main.
4. Verify: curl -i https://payments.do/ → 401 code: "missing_bearer" (token_unconfigured means step 1 was skipped); with the bearer → 200; curl -i -H "Stripe-Account: acct_x" https://payments.do/checkout → 401 connect_requires_auth. Confirm a Stripe test webhook still returns 200, and run a db.headless.ly Contact.qualify to confirm the customer sync path.

Non-blocking follow-ups noted in review

• GET / (health) is now gated: any external uptime monitor needs the header.
• The committed auth-gate tests use GET /customers/:id and POST /rpc as the gated examples; a money-moving route (POST /charges / POST /refunds / DELETE /subscriptions/:id) would document intent more directly. The gate is structural, so coverage is equivalent today.
• CI has been red on every run, including on main before this PR: actions/setup-node with cache: pnpm requires a pnpm-lock.yaml that is not committed, and @dotdo/events-sdk is file:../events-sdk, which does not exist on the runner. Fix separately.
• README's SDK section (PAYMENTS_API_KEY via rpc.do/env) predates this PR and does not line up with PAYMENTS_API_TOKEN; the RPC fallback it depends on is dead under the pinned rpc.do@0.2.x anyway (see the research note).
• Still open from this issue: delete POST /import and the RPC fallback; ADR 0023 id.org.ai JWT remains the intended end state.

[nathanclevenger]

Rollout state 2026-09-10 (coordinator):

• payments.do deployed at main 6ae2f8e (version aada0350): PaymentsInternal RPC entrypoint live; public export answers 401 token_unconfigured on every route except POST /webhooks (Stripe signature error, not 401) and GET /checkout; Stripe-Account pivot refused. Verified from outside.
• The interim PAYMENTS_API_TOKEN secrets set earlier today on payments-do, db-headless-ly, and api were deleted; the permanent state is no shared secret, service bindings as the boundary.
• Pending: deploy the two consumers (headless.ly #66 d41eb84, dot-do/api #32 8478235). A fresh clone cannot build them (workspace needs rpc.do, .do/db/parquedb/dist, id.org.ai/auth from nested submodules), so this runs from the owner's checkout: git pull && git submodule update --init, then pnpm deploy in apps/db and in .do/api. Until then their payments calls fail closed (401), which is the safe direction.
• Deploy note: @dotdo/capnweb had to be installed (--legacy-peer-deps) for the bundle to resolve; tracked as Migrate from the @dotdo/capnweb fork (0.4.0, Jan 2026) to upstream capnweb (0.12.0) rpc.do#56.

[nathanclevenger]

Consumer deploys withdrawn (owner, 2026-09-10): db-headless-ly and api are the February 2026 headless.ly-era build, not in production use (db.headless.ly 404s everywhere; api only holds the apis.do hostname with a placeholder 200). They will be replaced by Domains on the apis.do substrate (dot-do/apis map #1), so they are NOT being redeployed. headless.ly #66 and dot-do/api #32 stay merged as hygiene. End state: payments.do public export fails closed; the only sanctioned caller path is the PaymentsInternal service-binding entrypoint, to be bound by the new platform when it needs payments.