10

While I was developing the front-end side of my web project, I got an CORS protection error. Not surprising since my front-end project was not in the same origin. After some search on how to bypass CORS protection, I have found some proxy websites.

I do not want to mention the website names but, they usually work in this format:

https://acorsproxywebsite.com/https://example.com

When I have sent this request, I was able to send GET request and receive response from any CORS-disabled website.

How can the CORS proxy websites bypass the protection and get a response from any cross sources? Why can they send requests successfully but I can not? Is it possible to implement a similar structure so that I can bypass CORS protection from my front-end?

1 Answer 1

10

The CORS policy is enforced by the browser, not by the server. The server just sets a couple of HTTP headers telling the browser how it wants it to behave. There is nothing that forces a proxyserver to honor those headers, and it can add, edit or remove them like it can with any other headers.

So the proxy can send the request but you can not, because as a front-end developer you are bound by the limitations the browser puts on you. There is no way around that. You will either have to set appropriate CORS-headers on your back-end, or you'll have to continue to rely on proxies.

So is CORS and the whole same origin policy useless if it can be bypassed with a simple proxy? No! Since the request is now made to acorsproxywebsite.com any cookies or other authentication information for example.com will not be included automatically in the request by the browser. That means that the proxyserver is only exposing what itself can see, and not what some other potential victim can see.

4
  • 1
    Does this mean that the server which gets the request from corsproxy server allways get the same request IP of this corsproxy?
    – Nastro
    Commented Feb 1, 2019 at 20:22
  • 2
    @Nastro Yes. Any server that receivers a request through a proxy will see the IP of the proxy and not the client that first sent the request. (Unless the proxy disclose the clients IP in a custom header.) To the server, the proxy is the client.
    – Anders
    Commented Feb 2, 2019 at 9:07
  • To me the last paragraph raises the following question though: what is the point of CORS at all for non-authenticated requests, when an attacker can simply set up a proxy with proper headers (including preflight responses) to counteract it? I do realize authenticated requests are supposed to be the most vulnerable ones (and they're covered by this answer), but why is CORS even a thing for anything else when it's that easy to bypass? I'm probably missing something obvious though.
    – Jeto
    Commented Dec 19, 2020 at 22:44
  • 2
    "The CORS policy is enforced by the browser, not by the server." Perhaps the simplest and most insightful thing I've read about CORS. Commented Oct 28, 2023 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .