1

I've seen this pattern pop up in a couple of different teams. They have a server with a REST API and a frontend web project.

What commonly happens is the frontend developer finds their requests are being blocked by CORS, and they create a REST API for the frontend that just passes requests through to the main backend. This API eventually catches some business logic and turns into its own server, handling half of the backend responsibility separate from the true backend server.

How can this pattern be prevented? It feels wrong to spread business logic across two API projects and to have to run two APIs to use the frontend. Is there a proper way to make a "set-and-forget" CORS proxy for the frontend, without creating a dumping ground?

Improve this question
8
  • 1
    None of those teams considered correctly configuring the backend?
    – jonrsharpe
    Commented Feb 6, 2019 at 22:31
  • "They have a server with a REST API" <- Is "they" someone else? I would have thought there ought to be a separate rest service hosted specifically for developers. That service would need to allow CORS for the development machines. I hope you're not using a live service for development!
    – Dan Rayson
    Commented Feb 6, 2019 at 22:31
  • 1
    @Dagrooms Having read it twice, it's clear it's someone in a team at your place, seems I jumped the gun. I would think that it's the person who designed the rest service's job to set up CORS to allow the domains that your front-end developers are using. Once it goes live, obviously swap around your CORS config to allow live front-end servers. I can't imagine there's a real requirement that there needs to be a proxy service specifically for CORS...
    – Dan Rayson
    Commented Feb 6, 2019 at 22:39
  • 1
    enable-cors.org ...?
    – Dan Rayson
    Commented Feb 6, 2019 at 22:44
  • 1
    @Dagrooms I would say so... I still can't quite believe that there's a need for a CORS proxy service... In my limited experience setting up CORS it's always been a simple server-client relationship. I think the answer to your question is simply "There shouldn't be a cors proxy service in the first place." I would consider chalking it up to the front-end developers not communicating well with the back-end teams? A simple "Can this developer have access to the service please?" would probably solve it?
    – Dan Rayson
    Commented Feb 6, 2019 at 22:51

1 Answer 1

Reset to default
1

The only scenario where I can see that configuration is when main API is not published with a public subdomain, so you may mask it publishing an intermediate public “backend” to proxy requests to the API in the private network OR you have a front end-backend (Let’s say a CMS with a different ad-hoc front end in AngularJS, React or any other Client-Side technology ) that consume services from other API, so you have a mix of CMS functionalities and data coming from the other API, I have seen both cases.

Most CORS problems come from misunderstanding of this mechanism. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

If API is publicly exposed, then you just need to configure the Access-Control-Allow-Origin: For the calling subdomain (origin of request) so you only have to worry that nothing is changing headers when they’re sent.

Of course CORS serves for the purpose of safely sharing data between different servers, hosting different applications, as API may reject any request not coming from the subdomain specified at Access-Control-Allow-Origin:

Otherwise having two backends with different or complementary business logic may result on a disaster, as any change done to the front end may easily result in changing code in the two backends which makes it harder to maintain.

Improve this answer
3
  • I misunderstood why the API was originally made, it was just a separate project. It wasn't made to get around CORS issues. And yes, it looks like it is entirely private.
    – Dagrooms
    Commented Feb 25, 2019 at 19:53
  • 1
    "Of course CORS serves for the purpose of safely sharing data between different servers, hosting different applications, as API may reject any request[..]". This is misunderstanding how CORS works (to be fair the way CORS works is completely insane so that's no surprise): The API does not reject any request due to CORS, it just informs the client and then let's it reject the request. If you write your own client you have no trouble ignoring CORS completely. CORS is no security feature.
    – Voo
    Commented Oct 18, 2019 at 7:41
  • CORS (or more accurately the Same Origin Policy) is a security feature. Simply writing your own client isn't enough to defeat it unless you have privileged access to the system you want to attack. You'd have to write your own client, and get someone with privileged access to run it.
    – bdsl
    Commented Feb 17, 2021 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.