Cross-origin resource sharing
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.
Testpage for CORS requests
Use this page to test CORS requests. You can either send the CORS request to a remote server (to test if CORS is supported), or send the CORS request to a test server (to explore certain features of CORS): www.test-cors.org
10 Free to Use CORS Proxies
1. CORS Anywhere
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.
2. HTMLDriven
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.
3. Taskcluster
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.
4. thingproxy
thingproxy is a javascript proxy that solves the CORS problem, but it also serves a great function when it comes to HTTPS requests. Many browsers, in addition to CORS issues, have issues when handling requests for non-HTTPS resources from HTTPS requestors. thingproxy is designed to get around this and offers both the source code option and a free proxy at freeboard.io.
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.
5. Whatever Origin
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.
6. alloworigin
alloworigin is an interesting project. Initially a simple Django alternative to AnyOrigin and Whatever Origin, it is the only implementation between those two that is both currently usable and in active maintenance. The last commit for alloworigin was in 2019, and development seems somewhat active. It is basically the same as Whatever Origin in terms of use workflow, so if a current project is needed as an alternative to Whatever Origin, this is a great option – assuming these use of Django is compatible with your existing implementation.
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.
8. allOrigins
allOrigins is an interesting javascript solution in that content is pulled via the API in JSON/P or raw, and then delivered to the client for further use or transformation. This is more directly a proxy useful in the development of services that rely on other resources and pages rather than specific APIs – for instance, pulling data from Wikipedia.org without using an API is a good use case for this sort of proxy.
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.
9. Cloudflare
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.
10. YaCDN
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.
Conclusion
CORS is actually a quite simple system once you understand both the need for it and the underlying system that drives it. Implementing CORS can result in more granular security, yes, but it can also open up major new avenues for data interaction and transmission. Properly configured and created within a planned API architecture, CORS is a wonderful tool.
What do you think about CORS? CORS is sometimes configured with a wildcard to allow all – do you think our suggestions against this are too strict? Let us know in the comments below!