-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Describe the solution
Context
When developing on your local network, you can load your worker URL on other devices, such as your phone.
This is an invaluable feature, allowing you to test real devices – not just emulations on your dev machine.
Unfortunately, it also exposes a dev server which was not intended for production and has not been battle-tested for security vulnerabilities.
See https://nvd.nist.gov/vuln/detail/CVE-2023-3348 for a recent example of such a vulnerability.
Why is this being proposed?
It can be argued that developers don’t always want to preview their worker on other devices. When testing desktop browsers, it is more convenient to use the same machine. When on a public wifi network, like at a coffee shop, they most definitely do not expect to expose their machine implicitly.
When testing another device, we should encourage users to explicitly enable the feature and disable it as soon as they’re done.
See https://www.ryanfiller.com/blog/tips/sveltekit-local-network for justifications of why SvelteKit implemented this behaviour.
What is being proposed?
When starting the wrangler dev server, bind to an address only accessible by the local machine, by default.
When listing the addresses that have been bound, explicitly mention the dev server is or isn’t exposed on the local network. See an example from SvelteKit below:

Additionally, allow users to explicitly opt-in to expose the server to the local network. SvelteKit uses --host but, since this is already a wrangler dev flag, we can use --expose-network to indicate we’re exposing the server on the local network.
To encourage disabling this feature when not in use, we should also add a hotkey to wrangler dev which toggles the --expose-network config value.
Open Questions
- Is this a breaking change?
Users may already be running wrangler dev and expect the server to be exposed on their local network
It can be argued that this is a security fix and therefore overrides our no-breaking-changes guarantees
We've decided this is a breaking change and the label has been added to this issue.
- What should the opt-in flag/config-key be named?
SvelteKit uses--hostwhich is a pseudo-standard flag of frontend development servers for this behaviour. Other options:
--lan--expose-network
Still open to any feedback here, but we're preliminarily going with
--expose-network
–
This issue supersedes #2036. Although that issue is still valid, I will close it in favour of this one.