When developing applications, a CORS error can be an annoying and workflow-breaking error. While CORS prohibition is primarily designed to protect the end-user, it can often overcomplicate the data flow and cause development headaches. A simple solution to this is to use a CORS proxy.
Today, we’re going to look at some CORS proxies, as well as discuss in brief what the CORS problem foundationally is, as well as discuss some everyday use cases behind proxies.
What is CORS?
CORS, or Cross-Origin Resource Sharing, is one of two resource dynamics that are common in browser API communications (the other being “Same-Origin”). In essence, Same-Origin policies prevent Cross-Origin requests – requests that do not come from the same origin as the hosted data will be rejected, protecting the origin source from a variety of complex attacks including cross-domain scripts, redirects, and more.
While this is designed to protect the end-user, it can also be a significant development blocker. For this reason, developers often employ a proxy. Put simply, a proxy takes a request and passes it forward through a predetermined URL – in most cases, it passes this URL with a CORS header variable that removes the obstruction from the internal service.
There are some security implications here (which we’ll discuss in a moment), but ultimately, this proxy serves as a middleman transformative layer, allowing CORS issues to be bypassed entirely.
Proxy Use Cases
There are essentially two use cases for CORS proxies.
- Internal proxies: In some cases, CORS issues come from internally consistent, yet domain separated requests. In these cases, the URL and URIs might exist on servers that hold trust, but because they are on separate domains, CORS creates significant issues in their communications. The best solution for this type of use case is typically local installations and implementations.
- External proxies: In external cases, an API might need to reach out intermittently to external resources. Whether the case is that this happens seldomly enough not to warrant CORS management or that CORS is simply not compatible with the current API approach, there are times where CORS support is needed without the foundational processes on server to allow it. External proxies, typically handled by third-party servers, are a great solution here.
CORS Proxy Security Concerns
CORS proxies are extremely useful, but depending on their implementation, they can have a pretty glaring security hole. Proxies do one thing – they take a request and serve as a middleman to send that request elsewhere. What a proxy is essentially doing is carrying out a benevolent “man-in-the-middle” attack.
Such proxies place a lot of trust in the developer of the proxy as well as in their implementation of security. Some of the options on this list do log IPs and requests, and others have relatively opaque internal operations – when using them, then, the question becomes, “do I trust this developer with my request?”. This is especially important if you pass any sort of in-line authorization (which is typically bad development practice but is nonetheless not impossible to see in an internal environment).
There are options to get around this. Local proxies can help, especially if the implementation passes headers rather than pushes the content to a CDN or external proxy. At that point, however, you might as well ask yourself why you’re not simply enabling CORS handling on the server proper. In some cases, this is a strong argument; in other cases, the weight of enabling CORS and handling those headers might not be justified. A value judgment has to be made here – regardless, you should keep in mind that using any proxy carries with it a foundational risk.
Free CORS Proxy Servers
CORS Anywhere does what it says on the tin – it enables cross-origin requests to “anywhere.” The best thing CORS Anywhere has going for it is its simplicity – in essence, all you have to do is prefix the URL with the API URL for CORS Anywhere, and the proxy will handle the request on your behalf with appropriate CORS headers. You can also use something like npm to install cors-anywhere as a module and utilize its defined domain and port to do essentially the same thing on a local level.
HTMLDriven is a solution designed for “performing standard AJAX requests to 3rd party services”. As such, it’s a straightforward tool and has limited feature sets outside of proxying for requests. While it can be installed using a composer, there is also a relatively lightweight and extremely simple web-based implementation on its main page that can be used for simple requests.
Taskcluster is a collection of services, one of which is its CORS Proxy. The proxy is a relatively simple service that enables taskcluser services to make CORS requests through a system allowing for URL, method, headers, data, and rejection (specifically, rejectUnauthorized) headers. While still usable, like many on this list, this project is currently not being iterated upon – in fact, the GitHub where development is carried out is currently archived. As such, while this is a great solution, it should be considered a stopgap rather than a long-term solution.
thingproxy is pretty explicitly for small API calls – as such, requests and responses are both limited to 100,000 characters each. Additionally, each IP is throttled to only ten requests per second. This makes this proxy a great testing platform rather than a long-term proxy for production use.
Originally an open-source clone of AnyOrigin, Whatever Origin has since become the better of the two due to the simple fact that AnyOrigin is no longer operable. Whatever Origin is rather simple, and uses the same “proxy url” + “destination url” scheme as in other implementations. Notably, Whatever Origin claims better HTTPS support, and as such, may be a better solution for those utilizing HTTPS in their proxy-needing projects.
It should be noted that Whatever Origin, though still usable, is not currently maintained. For this reason, the project, while useful, should be considered within the frame of it being non-current.
7. Go Between
Go Between offers two different solutions for CORS proxy handling. First, it provides a pretty standard solution for simply prepending a URL with the proxy URL (specifically, adding “http://gobetween.oklabs.org/” before each request). The more interesting secondary solution is the use of domain mapping, allowing any domain to be mapped to any URI as a base bath. This is best used for production resources that routinely hit CORS issues while not itself necessitating CORS headers to any high level. That middle ground is often underserved, and Go Between is a wonderful solution for that specific use case.
That being said, this is a very niche solution and is only really useful in specific applications. A more generalist solution may be more appropriate depending on use case – if your use case is appropriate, however, allOrigins is a great implementation.
Cloudflare is arguably the most feature-rich solution on this list. Its CORS proxy solution is one aspect of a much more sophisticated offering. Cloudflare is a massive Content Delivery Network or CDN. As such, it offers security, reliability, and performance solutions well above and beyond what a CORS proxy is designed to do.
With that in mind, Cloudflare provides a pretty clean and straightforward method for CORS resolution. Cloudflare automatically detects cached assets through header investigation and passes the origin headers from the origin server to the browser in question. This is all done quite simply, and can be configured and edited using the internal API.
YaCDN isn’t really a proxy server by design and instead exists as a CDN (much like CloudFlare). That being said, it does have an explicit CORS proxy endpoint that simply prepends the YaCDN URL to the resource destination. Of note is that YaCDN is still being actively maintained and updated.
One of the great things about open development is that if you need something, there’s very likely a comprehensive solution somewhere. All of the choices on this list are great ones depending upon some specific use cases, requirements, and implementation restrictions – as such, any option here can be the right one for the right situation.
What do you think about this list? Did we miss any major CORS proxies? Let us know in the comments below!