Verify Host and Origin headers in dev server

[devongovett]

Previously we allowed all requests in the dev server, but this could potentially allow another website to access local source code.

This implements 3 mitigations:

1. Validate the Origin header matches an allowed host. By default localhost and local IP addresses are allowed. The existing --host option can be specified to use a different host. Set Access-Control-Allow-Origin to only that origin instead of *.
2. Validate the Origin header when a WebSocket connects. This allows localhost by default, or the --hmr-host/--host option.
3. Validate the Host header to prevent DNS rebinding attacks.

One problem is that reverse proxy services such as Cloudflare Tunnels no longer work due to Host validation. Setting the --host option does not work because that also sets the network interface, and the cloudflare host is not valid in that situation. We would need to add an additional option to either disable host validation or provide additional allowed hosts. Unfortunately we don't have a great place to put this. Environment variable? New CLI option? Seems important to solve this one.

Another downside is if you use custom hostnames (e.g. configured via /etc/hosts), these are not allowed by default. You'd need to manually set the --host option now, and only one at a time can be used. Would be nice if these could automatically be added to the allowed hosts (e.g. could do a reverse DNS lookup for 127.0.0.1), but would this then be susceptible to DNS rebinding?

Unless we can solve the above items this is also technically a breaking change...

[R4356th]

Since you are concerned about breaking certain workflows, have you considered introducing a new config or CLI flag that would revert this patch? It's far from ideal but other bundlers have done this in the past.

[gxy5202]

As a user of Parcel, I prefer Parcel to only allow local hosts and local IP addresses by default. If I need to customize the host name or release host verification and other functions, I can configure it manually, or there is an official plug-in that is specifically configured for the network. This plug-in allows all network access by default. Because I think most developers who use Parcel do so because of its simple and fast configuration.

[G-Rath]

@devongovett it would be good if there could be some movement on this, as it's forcing us to re-evaluate if we stick with Parcel as our build tool.

Personally, I've found it's often considered acceptable to do what could be considered a breaking change as patch release if they're for security issues as arguably they're a bug, but if you feel this is still too big of a change to ship like that I would recommend releasing it as a new major asap with that being the only breaking change - that way it should be very easy for downstream packages to upgrade to that new major without needing to do their own new major, and consumers like myself can safely use e.g. overrides to force that major being used without having to worry about other breaking changes that the library we're waiting on might need to account for

[mattparker]

Our build stops if npm audit fails - leaving a CVE is breaking our workflow. Would be very grateful if one way or another this could be released.

[devongovett]

First of all I don't think this is a particularly bad issue - if you are building a web app you generally expect people to download the code for it. Even with the mitigations here, anyone on the same network can still access the code. "Fixing" this makes Parcel worse for users, breaking common workflows like testing from different devices on your local network, or via proxy servers. An alternative would be a new CLI option --no-cors that disables cors headers for those people who really care. But again this does not stop anyone from accessing the code, just web browsers that respect cors headers.

[Pomax]

as an official NIST CVE and GHSA, unfortunately, even if it doesn't feel particularly bad (and I agree, it feels like "yeah, that's what a dev server does, why is this a CVE?"), this now flags Parcel as a security vulnerability in literally every vulnerability tool. So without a patch and new version that can be pinned/set as new lowest version, Parcel effectively can't be used anymore by loads of folks because their orgs (some for legal reasons) don't allow code with security vulnerabilities to land or even continue to be used in development until a patch has been issued. Which also includes being able to use frameworks that use Parcel under the hood, like Gatsby, etc.

[devongovett]

Please see #10216 (comment). You are welcome to offer a better suggestion for a patch. This one is too restrictive and breaks too much.