Keep the Vite dev server on localhost whenever you can. If you must reach it from a phone, a container or a tunnel, set an explicit server.allowedHosts list and leave server.fs.strict on. Vite's docs warn that setting allowedHosts to true lets any website request your dev server through DNS rebinding.
What the settings do
All of these come from Vite's server options page, which applies to the dev server only.
| Option | Default | What it controls |
|---|---|---|
| server.host | localhost | Which IP addresses the server listens on. Setting it to 0.0.0.0 or true listens on all addresses, including LAN and public ones |
| server.allowedHosts | an empty list | Hostnames Vite will respond to. localhost, domains under .localhost and all IP addresses are allowed by default |
| server.fs.strict | true | Restricts serving files outside the workspace root |
| server.fs.allow | workspace root detection | Which directories can be served through the /@fs/ path |
Why allowedHosts exists
Vite's documentation says that setting allowedHosts to true allows any website to send requests to your dev server through DNS rebinding attacks, letting them download your source code and content. It recommends always using an explicit list of allowed hosts, and points to a security advisory with details. It also says to never add top level domains like .com to the list, because anyone can buy a domain and control the IP address it resolves to.
A 2025 advisory worth knowing
GitHub's advisory for Vite, published in January 2025, describes the dev server letting any website send requests and read the response, because of default CORS settings and missing validation of the Origin header on WebSocket connections. It warns the issue applied even to people who only ran the dev server on their own machine without exposing it to the network. Patched versions were 6.0.9, 5.4.12 and 4.5.6. The advisory lists mitigations for the CORS part, such as setting server.cors to false or limiting its origins, and notes there was no mitigation for the WebSocket origin part other than upgrading.
The lesson is plain. A dev server is software with a security history. Update it like any other dependency.
Steps to expose a dev server safely
- Ask whether you need it. Often a tunnel or a staging deploy is better than opening the dev server.
- Bind to the narrowest address that works. Avoid listening on all addresses on a shared or public network.
- Set allowedHosts to the exact hostnames you use. Do not use true.
- Leave server.fs.strict at its default of true, and keep server.fs.allow narrow if you set it.
- Do not run the dev server on a machine that holds production credentials.
- Keep Vite on a patched version. A dependency scan will flag known advisories for you.
Dev server versus build output
Everything here is about development. A production build should be served by a normal web server with your usual headers. The environment variable rules for what ends up in the browser are a separate topic, see Vite env prefix: what reaches the browser.
Safeguard's dependency scanning and reachability analysis show which advisories in your build tooling affect code you run, and you can start with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how advisories are sorted by whether the vulnerable code is reachable.
Quick check
Is localhost enough to protect the dev server?
Not always. The January 2025 Vite advisory affected people who ran it only on their own machine, so patching matters too.
Can I set allowedHosts to true on a trusted network?
The docs recommend an explicit list instead, because true allows any website to reach the server through DNS rebinding.
Sources
Last reviewed: 19 October 2026.
