Skip to content

CORS localhost requests are considered invalid host and get blocked #5603

Description

@RedMser

Bug Description

If webpack-dev-server gets "no-cors cross-site" requests, localhost is not considered an allowed host and a 403 Forbidden is returned.

By explicitly adding allowedHosts: ['localhost'] to the webpack config, the bug is circumvented.

Link to Minimal Reproduction and step to reproduce

In the following project, an iframe is constructed from a blob HTML string. The iframe contains a script tag which refers to a resource URL which is hosted by webpack dev server.

http://github.com/RedMser/bug-webpack-dev-server-corb

See the readme in the repo for reproduction steps.

Expected Behavior

Requests to localhost should succeed, even if they originate from a "no-cors cross-site" context.

Actual Behavior

The request fails with a 403 Forbidden response.

Image

Environment

System:
    OS: Windows 11 10.0.26100
    CPU: (4) x64 Intel(R) Xeon(R) Platinum 8462Y+
    Memory: 2.84 GB / 19.00 GB
  Binaries:
    Node: 24.11.1 - C:\nvm4w\nodejs\node.EXE
    npm: 11.6.2 - C:\nvm4w\nodejs\npm.CMD
  Browsers:
    Chrome: 141.0.7390.123
    Edge: Chromium (141.0.3537.57)
    Firefox: 140.5.0 - C:\Program Files\Mozilla Firefox\firefox.exe
    Internet Explorer: 11.0.26100.1882
  Packages:
    webpack: ^5.102.1 => 5.102.1
    webpack-cli: ^6.0.1 => 6.0.1
    webpack-dev-server: ^5.2.2 => 5.2.2

Is this a regression?

None

Last Working Version

No response

Additional Context

Responsible is the cross-origin-header-check middleware.
In particular, isValidHost calls isHostAllowed which contains following comment:

// always allow localhost host, for convenience
// allow if value is in allowedHosts
if (Array.isArray(allowedHosts) && allowedHosts.length > 0) {

According to this outdated comment, localhost should be always allowed, but there is no code that actually ensures this here!
isValidHost does check for localhost among other things, but validateHost == false in this particular instance.

It might be caused by the refactor in 6045b1e but I did not investigate further. This used to work in the past so it's likely a regression, let me know if more info is needed.

Activity

  1. shubham220420 commented on Nov 12, 2025

    @shubham220420

    Hey I want to work on this issue can you assign it to me?

  2. alexander-akait commented on Nov 12, 2025

    @alexander-akait
    Member

    @RedMser We should fix commens and you should use allowedHosts: "all" or provide real hosts, that is expected to prevent - GHSA-4v9v-hfq4-rm2v and GHSA-9jgg-88mc-972h

  3. Muskan-shukla910 commented on Jan 8, 2026

    @Muskan-shukla910

    Hey sir I want to work on this issue can you assign it to me?

  4. Jeston10 commented on Jan 25, 2026

    @Jeston10

    @Branch Moderators, I would like to work on this issue. Can i please get assigned for this.

  5. added a commit that references this issue on Jan 25, 2026
    7ba6c0e
  6. Jeston10 commented on Jan 25, 2026

    @Jeston10

    @alexander-akait Sir I have raised a PR, If possible I would like it to be reviewed. I added a test case for the issue and removed the test case after testing if it works. I would like to know if I should include test case again. Thank you so much Sir.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions