Browser apps frequently need to fetch URLs from origins that don't return CORS headers — git remotes (GitHub/GitLab/Gitea), other Solid pods exposing linked data, ActivityPub actors, Nostr relays' HTTP endpoints, RSS/Atom feeds, images, etc. Public CORS proxies (cors.isomorphic-git.org, etc.) work but introduce third-party trust, privacy, and uptime concerns.

JSS already has the building blocks (`src/utils/ssrf.js`, WAC, optional `--pay`) for a self-hosted, authenticated CORS proxy that any browser-side Solid app can use. This issue tracks the general-purpose feature; the git-specific request in #377 is a special case (proxy a git URL through this).

Phase 1 — WAC-gated, free

Estimate

~250–400 LOC handler + a handful of tests + flag plumbing in `bin/jss.js`, `src/config.js`, `src/server.js`. 1–2 days for a competent dev.

Phase 2 — optional `--pay` integration (deferred)

Layered on top of Phase 1:

• Per-request debit at `--pay-cost`
• Optional `--pay-per-byte` for bandwidth pricing
• Free-tier rate limit per WebID before paid tier kicks in
• 402 ↔ 401 mapping so git clients (which don't speak 402) can still surface the gate as a credentials prompt

Not part of v1; tracked here for context.

Use cases unlocked

• Browser-side git via JSS Git cloning from any host without third-party proxy (closes Feature: JSS as a CORS proxy for git remotes (with optional paid access via HTTP 402) #377)
• Browser-side linked-data follow-your-nose fetches across pods
• Browser-side ActivityPub clients fetching foreign actors
• RSS/Atom readers in pod-hosted apps
• Image / video embedding from non-CORS hosts
• Webledger lookups from a browser
• Anywhere a Solid browser app currently has to either give up or use a third-party proxy

Risks / caveats

• SSRF is the dominant risk. This endpoint by definition fetches arbitrary URLs. Existing `src/utils/ssrf.js` covers initial-URL validation; the new work is re-validating every redirect target (otherwise an attacker hosts a 302 to `169.254.169.254`).
• Open-relay reputation: an unauthenticated/public proxy will get added to spam blocklists and abuse reports. The WAC gate is the mitigation — pod operators control their own audience.
• Resource exhaustion: bandwidth and memory bounds are required. `--cors-proxy-max-bytes`, request timeout, and redirect cap are non-optional.
• Header smuggling: be deliberate about the request-header allowlist. `Cookie`, `Authorization`, and `Origin` need explicit policy. Phase 1 default: forward `Authorization` + `Git-Protocol` + `Content-Type` + `Accept*`; strip the rest.

Refs

• Feature: JSS as a CORS proxy for git remotes (with optional paid access via HTTP 402) #377 — git-specific original framing (close against this once Phase 1 lands)
• git handler: allow git-protocol header in CORS preflight responses #371, git handler: collapse multi-slash in URL before forwarding to http-backend (#373) #374 — git CORS work that the response-side header logic generalizes from
• CORS headers missing on Fastify-level error responses (FST_ERR_BAD_URL et al) #376 — Fastify-level errors don't carry CORS headers (separate, applies to this proxy too)
• `src/utils/ssrf.js` — existing SSRF guard
• `src/handlers/git.js` — `GIT_CORS_HEADERS` pattern to generalize
• `src/handlers/pay.js` — Phase 2 integration target
• isomorphic-git CORS proxy spec: https://isomorphic-git.org/docs/en/cors