The deep-dive
Avoid in production
Public CORS proxies (cors-anywhere, allorigins, etc.)
Fine for a demo or a hackathon, dangerous for a product. They rate-limit aggressively, can disappear without notice, and your users' traffic transits a server you don't operate. The public cors-anywhere.herokuapp.com demo is opt-in: you have to request temporary access on its demo page, and it is rate-limited and not meant for production use.
When to use: a one-off prototype where the cost of breakage is zero.
Works, until it doesn't
A DIY Cloudflare Worker (or Lambda, or Fly app)
A 50-line Worker that adds CORS headers is the right call for one project at one company. The cost shows up later: when you need API keys, per-project quotas, abuse handling, observability, and a way to revoke access without a redeploy. Each one of those is a couple of days of work. Compounded across a team, it's the proxy infra you didn't want to own.
When to use: a single internal tool, never expected to grow.
Right answer for some teams
Your own backend (Express, Fastify, Lambda, etc.)
If you already have a backend service and the third-party call is part of a server-side workflow, just put it there. You get full control, full auth, no relay layer. The trap is using "we need a backend anyway" as the reason to spin up a service whose only job is to forward requests. That is where teams can spend weeks reinventing a relay.
When to use: the backend already exists, or the integration needs server-side state (secrets, queues, retries).
Why we built it
corsproxy.dev
A managed relay aimed at the case the other three options handle badly: a frontend team shipping production browser integrations who doesn't want to own proxy infrastructure. You get origin-locked API keys, exact daily quotas, SSRF protection, secrets kept server-side with managed upstream headers, edge caching (Pro), header overrides, and a dashboard with your last 100 calls on day one. Pro is $5/month for 20,000 requests a day. The tradeoffs: Free and Pro have no SLA (Enterprise plans include one), only GET and POST are supported, and your traffic transits a service you don't operate. If you later want full control, there is a separate, simpler open-source relay (MIT, written in Go) you can self-host. It is not the code behind corsproxy.dev and has no API keys, quotas or managed headers, so moving to it means rebuilding those parts yourself.
For narrower comparisons, see corsproxy.dev vs corsproxy.io, corsproxy.dev vs cors.sh and the free CORS proxy comparison.
Create a free account · API docs
Status · GitHub