API gateway vs reverse proxy vs CORS proxy: what each one does

“Proxy” is one of the most overloaded words in web development. A reverse proxy, an API gateway and a CORS proxy all sit between a client and a server and forward requests, so they are easy to confuse. But they exist for different reasons, serve different people and fail in different ways.

This article compares API gateway vs reverse proxy vs CORS proxy: what each does, where they overlap, and how to pick.

The short version

• A reverse proxy sits in front of your servers and handles traffic on their behalf.
• An API gateway sits in front of your APIs and manages how clients use them.
• A CORS proxy sits in front of someone else’s API so a browser can call it.

The first two protect and organize what you serve. The third helps a browser consume what others serve.

What a reverse proxy does

A reverse proxy accepts requests from the internet and forwards them to one or more backend servers that clients never talk to directly. Nginx, HAProxy, Caddy and Traefik are common examples.

Typical jobs:

• TLS termination: handling HTTPS certificates in one place.
• Load balancing: spreading requests across several backend instances.
• Routing: sending /api to one service and / to another.
• Caching and compression of responses.
• Basic protection: request size limits, timeouts and IP filtering.

A reverse proxy works at the level of hosts, paths and connections. It generally does not know who your API’s customers are or what their plan allows.

What an API gateway does

An API gateway is a reverse proxy with an opinion about APIs. It sits in front of your services and adds the concerns that come with exposing an API to many clients. Kong, Tyk, Apigee and the API gateways of the major clouds are examples.

On top of routing, a gateway typically handles:

• Authentication with API keys, OAuth tokens or JWTs, before requests reach your code.
• Rate limiting and quotas per client or per plan.
• Request and response transformation, such as adding headers or reshaping payloads.
• Analytics and logging per client.
• Versioning and routing between API versions.
• A developer portal for issuing keys and documenting endpoints.

The defining feature is that the gateway understands clients and policies, not just servers and paths.

What a CORS proxy does

A CORS proxy solves a browser-specific problem. When your page calls an API on another origin, the browser only lets your script read the response if the API sends the right CORS headers, such as Access-Control-Allow-Origin. Many APIs don’t, because they never expected to be called from a browser. (See What is CORS? for the full background.)

A CORS proxy fetches the resource server-side, where CORS doesn’t apply, and returns it to your page with the CORS headers added:

// Instead of calling the API directly...
fetch('https://api.example.com/data');

// ...call it through the proxy, which adds the missing headers.
fetch(`https://cors-proxy.example/proxy?url=${encodeURIComponent('https://api.example.com/data')}`);

The simplest CORS proxies, such as the open-source cors-anywhere project, do little more than that: fetch the URL, copy the response and add Access-Control-Allow-Origin.

The trouble with open CORS proxies

A CORS proxy that anyone can use for any URL is an attractive target:

• Abuse. Strangers can route scraping, spam or attacks through it, under your IP addresses and your bandwidth bill.
• SSRF. Without a guard, a proxy that fetches arbitrary URLs can be pointed at its own internal network or cloud metadata service. See SSRF explained.
• Credential leaks. If users send API keys through someone else’s proxy, the proxy operator can see them.
• Reliability. Free public instances are usually rate-limited or restricted and come with no guarantees.

That is why production setups either run their own locked-down proxy or use a CORS proxy with gateway features.

API gateway vs reverse proxy vs CORS proxy at a glance

	Reverse proxy	API gateway	CORS proxy
Sits in front of	Your servers	Your APIs	Third-party APIs
Main user	Your infrastructure	Your API’s clients	Browser apps
Knows about clients and plans	Rarely	Yes	Only if it has gateway features
Adds CORS headers	Can be configured to	Usually configurable	Its core purpose
Typical concerns	TLS, load balancing, routing, caching	Auth, quotas, transformation, analytics	CORS, abuse control, SSRF safety
Examples	Nginx, HAProxy, Caddy, Traefik	Kong, Tyk, Apigee, cloud gateways	cors-anywhere, hosted CORS proxies

Where they overlap

The lines blur in practice:

• Many reverse proxies can add CORS headers, rate-limit and check simple tokens, which covers a lot of API gateway territory for small APIs.
• Many API gateways are built on a reverse proxy core.
• A CORS proxy with per-key policy, quotas and authentication is effectively an API gateway pointed outward, at other people’s APIs.

So the useful question is not “which category is this product?” but “which problem do I have?”.

How to choose

You run the API and want to manage who uses it. Use an API gateway, or a reverse proxy with gateway features if your needs are simple. If browsers call your API, configure CORS there, at the source. The guide to the missing Access-Control-Allow-Origin header shows how.

You run servers and need TLS, routing or load balancing. Use a reverse proxy. You probably already have one, even if your platform hides it.

You need to call an API you don’t control from the browser. You need something server-side to make the call: your own backend route, or a CORS proxy. Choose a CORS proxy that:

• requires a key and lets you restrict it to your own origins;
• enforces quotas and rate limits per key;
• keeps upstream credentials server-side instead of sending them from the browser;
• refuses private and internal destinations.

You need to keep a secret key out of the browser. A plain CORS proxy doesn’t help, because the key would still travel from the page. Use a backend route or a gateway with a secrets vault, as covered in You can’t hide an API key in frontend code.

Where ProxifyEdge fits

ProxifyEdge is a CORS proxy built with API gateway features, aimed at browser apps calling third-party APIs. It adds the CORS headers your page needs, and around that it provides what an open proxy lacks (documentation):

• Keys locked to your origins, with test keys for development.
• Quotas and rate limits per plan and per key, reported in response headers.
• A secrets vault that inserts upstream credentials server-side, only for the hosts you allow.
• Signed URLs for keys that must not be usable outside your app.
• An SSRF guard that refuses private and internal destinations, including on redirects.

It is not a replacement for a reverse proxy in front of your own servers, or for the API gateway you would put in front of an API you publish.

Key takeaways

• A reverse proxy fronts your servers, an API gateway manages clients of your APIs, and a CORS proxy lets browsers consume other people’s APIs.
• API gateways are distinguished by understanding clients and policies: auth, quotas, transformation and analytics.
• Open CORS proxies invite abuse, SSRF and credential leaks; production use needs keys, origin locking, quotas and an SSRF guard.
• If you own the API, fix CORS at the source; if you don’t, call it from a backend route or a properly secured CORS proxy.
• Choose by the problem you have, not by the product category.