Comparison

Four ways to get your frontend talking to a third-party API.

Most teams don't have a CORS problem so much as an "I need to ship an integration this week" problem. The table below compares the four common answers once production gets involved, including where corsproxy.dev is the weaker choice.

  Public CORS proxy
cors-anywhere, allorigins
DIY Cloudflare Worker
your own ~50 LOC
Your own backend
Express/Fastify/Lambda
corsproxy.dev
managed relay
Time to first request ~1 minute ~30 minutes Hours to days ~2 minutes
Stable for production No (demo-grade) Yes, you maintain it Yes, you maintain it No SLA on Free/Pro; Enterprise SLA
API keys per project No Build it yourself Build it yourself Yes
Daily rate limits Set by the operator Build it yourself Build it yourself Yes, exact per account
Keep API secrets out of the browser No Build it yourself Yes Managed upstream headers
Lock a key to your site No Build it yourself Build it yourself Allowed origins per key
Edge caching No Build it yourself Build it yourself ttl (Pro)
Per-request header overrides Varies Build it yourself Build it yourself reqHeaders / resHeaders
Request logs / usage dashboard No Wire up Logpush Build it yourself Yes
SSRF / private-network protection Varies Easy to forget If you remembered Private, loopback and link-local targets blocked, plus a DNS check
Abuse handling Operator's policy, not yours You design it You design it (full control) Quotas, origin locks, SSRF block
Self-host option Some are OSS By definition By definition Separate, simpler MIT relay
Ongoing maintenance None for you, and no control You + Cloudflare changes Patching, scaling, on-call Handled by us
Cost at low volume Free ~Free on CF Hosting + your time Free tier

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

Start free in two minutes.

500 requests/day on the free tier. No credit card. Prefer to run your own? The open-source relay is on GitHub.

Start free Read the docs