Make CORS configurable

[mbrevda]

de85afd seems to have overcorrected when it came to fixing a cors vulnerability. Some level of configurability would be greatly appreciated.

[evanw]

Yes, I agree. I don't need this myself though, so I'll need to lean on others such as yourself for a set of use cases to design an API around.

Please describe what you are trying to use it for, what isn't working for you, and what you would like for esbuild to do instead.

[evanw]

(For myself) Another report for this is #4110, so I'm linking it here. That issue report has more information about a specific problem and proposed solution. I'm wondering if that proposed solution is sufficient for other use cases as well or not.

[mbrevda]

In this instance, I was trying to get my local build to work with ngrok, but the requests were refused because they did not come from localhost and because they not have cors enabled (due to the remote address).

(As an aside, perhaps the original premise can be questioned: is running a dev web server a security issue? Isn't that just "working as intended"?)

[SPWizard01]

I myself got into this recently (probably as part of an update to esbuild package), as a result I had to setup a node server which would then internally forward requests to esbuild, which is far from ideal :)

The use case I have is when debugging websites where I have no control over in the backend.
Imagine you have an ability to deploy JS app to a website where it will be executed, but then you reserve the right to set a localStorage variable or something else where instead of pulling dependencies from said website it will pull from your localhost aka debug in prod.
However because of CORS settings on said website, you cannot do it easily in esbuild now.

Why I would do that at all?
Because said server can have APIs that are CORS protected/under auth, so you cannot just localhost:8000 it and call API's :)

The workaround works now, but its not ideal, I don't like the idea of using 2 ports for single purpose :)

I believe this should be implemented as part of serving feature of esbuild, webpack had it, bun has different approach altogether on this, but the ability for additionalHeaders: {} would be greatly appreciated.

As for the scenario above I do get why this had to be done, stealing secrets etc. would be possible I guess, but unless you are visiting questionable sites I would see it as highly unlikely :)

[evanw]

In version 0.25.3 (which was just published), a custom host passed to --serve= or serve() will now be included in the list of allowed hosts. Please try this out and let me know whether this fixes your issue or not. If it does then I can close this issue, otherwise it would be good to understand what additional requirements there are regarding these use cases.

(As an aside, perhaps the original premise can be questioned: is running a dev web server a security issue? Isn't that just "working as intended"?)

That was my original premise when I wrote the development server. However, I believe the linked report offers sufficient justification for this being undesirable default behavior, which is why I have changed esbuild's behavior here. The responses from the development server may include sensitive content such as API keys. I consider allowing any website you visit to extract that information to be a security issue.

[hesxenon]

hmmm, maybe I misunderstood your comment @evanw, but I thought that this:

serve({
  port: 3000,
  host: "0.0.0.0"
})

would allow any origin on localhost to access the dev server resources?

Requesting it from a different port though does not seem to work, and the list of hosts also does not include "0.0.0.0".

[SPWizard01]

I also get CORS error with 0.25.3 when using the approach I described above:
(localhost:33355 is esbuild serve)

It does not seem to respond with proper CORS headers

Even though it reports 200, the browser wont load it because of missing headers: