Adding a security section in the documentation?

[AoDev]

Hello,

While I have a general understanding of web security, when I checked the documentation I saw that it would pretty easy to set this up. But the security question popped up in my mind immediately.

So I wondered how far is this secure, what options are "dangerous" and what potential risks are associated with using a solution like "cors-anywhere".

I guess the typical use case is to proxy ajax requests to a Web API that may or may not contain sensible information.

I'd like to add such section, like do/don't do or maybe just a link to a relevant article?

What do you think?

[Rob--W]

The typical use case is to access a public resource that is not available due to the lack of CORS headers. As the operator of the server, the main risks are:

• DoS - Denial of service of your server via resource exhaustion, if others can use your server to proxy any request. You can and should use the CORSANYWHERE_WHITELIST environment variable (or if you use CORS Anywhere as a library - the originWhitelist option) to mitigate this risk. If you use the default server implementation and want to allow many origins, but with a limited number of requests per time period, then the CORSANYWHERE_RATELIMIT environment variable can be used.
• If you operate an open proxy, others may use your server to hide actual IP from the destination server. Include the source IP in he request header with the xfwd option to discourage this.
• The proxy server must not be placed in a network where sensitive resources are accessible via an intranet, or even localhost. Otherwise these resources can be leaked via proxy requests. I once planned to address this in #78, but haven't changed the logic yet.

[AoDev]

@Rob--W Thanks for your answer, I already learnt something :)

• Regarding the xfwd header, it seems pretty useful and would be nice to just enable it in the options. Could we add this as a feature? My use cases needs it. I know how I'd do it with koa or express but with cors-anywhere, how would it be?

• Anything I could do to help with #78 ?

• Regarding "leaking". I've seen a few people writing tutorials using the Heroku example without changes. Heroku logs all requests from its router. Is it possible to leak any data because of this?

[Rob--W]

Regarding the xfwd header, it seems pretty useful and would be nice to just enable it in the options. Could we add this as a feature? My use cases needs it. I know how I'd do it with koa or express but with cors-anywhere, how would it be?

If you are considering Koa or Express, then you probably intend to use CORS Anywhere as a library. In that case, you can simply set xfwd: true as an option. The server.js at the root of this repo is just an example, used on Heroku. This project can be used as a library to create a server, as documented in README, and exemplified in server.js and test/test.js and test/test.js.

Anything I could do to help with #78 ?

If you have an actual need for the functionality, please describe your use case I didn't add a commit yet, because it was unclear to me how others would like to configure the feature (e.g. via environment variables); I have stashed an implementation since forever (most of the relevant code is pasted inline in #78), but absent concrete use cases I haven't added the patch to the master branch yet.

Regarding "leaking". I've seen a few people writing tutorials using the Heroku example without changes. Heroku logs all requests from its router. Is it possible to leak any data because of this?

I think that you misunderstood my comment. The security issue is not "leaking" client URLs to the server, because by definition the client trusts the proxy server to handle requests on behalf of the client. Heroku does indeed offer a live log of requests (and if needed, I analyze these logs to counter abuse, e.g. as done in #45 and #129).

The leak that I mentioned in my previous comment is when there is a server in your network (potentially a service at localhost on your computer) that is not supposed to be reachable by others outside your network. Usually, a firewall protects the resource from external access, and the Same-origin policy of web browsers prevent other web pages that you are visiting from reading data from such services. However, if you start a CORS proxy in your network, then these protections can be bypassed. The following two cases are most likely:

• If you use a CORS proxy on your local computer, then any website that knows the proxy and connects to the proxy can bypass the cross-origin restrictions of your browser to access these local services. If there is no additional authorization requirement, then these services may leak information.
• If you offer a proxy (any kind, not just CORS Anywhere) on a server, then anyone who can connect to this server is able to access resources that can be reached via the proxy server. If the proxy server has access to an intranet with sensitive documents, then these documents can be leaked.

For these reasons, it's important to put the proxy on a network where it cannot access sensitive resources.

[AJamesPhillips]

I'm sure you've already seen it. This issue was mentioned in this penetration test report specific to AWS EC2 meta-data exploit: https://www.certik.com/resources/blog/technology/cors-anywhere-dangers-of-misconfigured-third-party-software