"Invalid Host/Origin Header" warning

PLEASE READ

We are working on this problem. It is regression problem after fixing security error. Security issues are always high priority and we would not want to revert it, but it is require some changes in sockjs/sockjs-node#247, we have workaround for this problem #1608, but need some feedback. Feel free to feedback.

Fast workaround (put it in your devServer property in config):

disableHostCheck: true

We apologize for the situation. Thanks for helping us do webpack better. ⭐ ⭐ ⭐

Operating System: macos 10.14.2
Node Version: 11.5.0
NPM Version: 6.4.1
webpack Version: 4.28.1
webpack-dev-server Version: 3.1.11

This is a bug

Code

  // webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  entry: [
    './src/main.css',
    './src/main.js'
  ],
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'index.js'
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/main.html'
    }),
    new MiniCssExtractPlugin({
      filename: 'index.css'
    })
  ],
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader'
        ]
      },
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: 'babel-loader'
      }
    ]
  },
  stats: {
    children: false,
    modules: false
  },
  devServer: {
    proxy: {
      '/api': 'http://localhost:3000'
    },
    stats: {
      children: false,
      modules: false
    }
  }
};

Expected Behavior

No warnings

Actual Behavior

Getting "Invalid Host/Origin Header" warning in browser console

For Bugs; How can we reproduce the behavior?

install webpack-dev-server@3.1.11 and run (v3.1.10 working as expected).

@ravshansbox it is security fix, looks you origin than you use in config, you can use disableHostCheck: true in you case, anyway can you create minimum reproducible test repo?

@evilebottnawi yes, sure, here you are: https://github.com/ravshansbox/webpack-dev-server-sample

with disableHostCheck: true there is no warning.

@ravshansbox thanks, i will look in near future, but if original is not same it is normal have this error

I have the same issue. Problem here is that browser does not send origin header at all. Here my debug of connection object

SockJSConnection { _session: Session { session_id: undefined, heartbeat_delay: 25000, disconnect_delay: 5000, prefix: '/sockjs-node', send_buffer: [], is_closing: false, readyState: 1, timeout_cb: [Function], to_tref: Timeout { _called: false, _idleTimeout: 25000, _idlePrev: [Object], _idleNext: [Object], _idleStart: 1740, _onTimeout: [Function], _timerArgs: undefined, _repeat: null, _destroyed: false, [Symbol(asyncId)]: 6686, [Symbol(triggerAsyncId)]: 6679 }, connection: [Circular], emit_open: null, recv: WebSocketReceiver { ws: [Object], connection: [Object], heartbeat_cb: [Function], thingy: [Object], thingy_end_cb: [Function], session: [Circular] } }, id: 'da07ccdf-4d74-4fed-a48b-6d76247e97af', headers: { host: 'localhost:8080', 'user-agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36', 'accept-language': 'pl,en;q=0.9,en-US;q=0.8,fr;q=0.7' }, prefix: '/sockjs-node', remoteAddress: '127.0.0.1', remotePort: 37412, address: { address: '127.0.0.1', family: 'IPv4', port: 8080 }, url: '/sockjs-node/599/ngnhxajl/websocket', pathname: '/sockjs-node/599/ngnhxajl/websocket', protocol: 'websocket' }
`

I am seeing this issue as well with 3.1.11. Rolling back to 3.1.10 fixes it.

Also, got this issue after upgrading to 3.1.11

I also am getting this error in Firefox 64.0 with version 3.1.11. Reverting to 3.1.10 fixes it.

I confirm, the same problem.
Manjaro linux (4.19.8-2-MANJARO)
Firefox DE 65.0b2
Node LTS (10.14.2)

Same problem here

Please read #1604 (comment)

Please try https://github.com/webpack/webpack-dev-server/releases/tag/v3.1.12

I can confirm that the issue still exists.

I can also confirm that the issue still exists

Please don't spam Same problem here or issue still exists, better create minimum reproducible test repo, it is allow to fix all edge cases, thanks!

I checked request sent to dev-server via Chrome in localhost, request doesn't have Origin header.

{ host: 'localhost:8080',
  'user-agent':
   'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36',
  'accept-language': 'ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7' }

checkHeader will return false when value is empty, so this issue still exists, I think.

webpack-dev-server/lib/Server.js

Lines 644 to 646 in e614308

    
           if (!hostHeader) { 
        
             return false; 
        
           }

Sockjs will remove Origin header.
Ref. sockjs/sockjs-node#247

In my opinion, it is better to revert #1603 until sockjs/sockjs-node#247 is merged.

@3846masa let's wait some time and revert it, maybe we can implement workaround on our side, need investigate, feel free to do it, thanks

I tried to add workaround (#1608).
It works and resolves this issue in my environment. Please check it.

@ravshansbox Can you test #1608 PR?

Any who can test the PR please leave feedback

This also affects projects created with @vue/cli - tested a few minutes ago with 3.1.12.

@lbogdan 3.1.12 only fix compatibility with node@6, please check #1608

#1608 is working for me (Node 11.5.0 and SockJS 0.3.19)

@vue/cli afectado, que pasooooooooooooo

Please tests https://github.com/webpack/webpack-dev-server/releases/tag/v3.1.14

Looks like the issue has been solved. Thanks

I'm on 3.1.14 and one could argue that my setup is a bit extreme.

I'm using public: 'mydomain.dev' and port: 8070 setting in devServer section of the config file. Charles Proxy rewrites all requests from mydomain.dev, subdomain1.mydomain.dev, subdomain2.mydomain.dev etc to localhost:8070.

This way I have a multi-tenant environment locally, with one web app, but the behaviour is different depending on the hostname. Main hostname (without subdomains) is a lookup page to choose a tenant. Choosing one redirects to one of the subdomains - same web app bootstraps, but discovers different hostname and loads selected tenant's data accordingly.

With latest updates (3.1.14) this setup does not work anymore. I can either set mydomain.dev OR subdomain1.mydomain.dev in settings. Setting one breaks sockets for the other.

Yes, doing disableHostCheck works, I never noticed that option before. My issue is sorted, I thought that it could lead some people with similar setup here, so this is more of an FYI.

@kamilbrk thanks for feedback, can we setup very minimum reproducible test repo? Maybe we can solve on our side without disableHostCheck

The issue has been resolved. Great thanks for support. 👍👏

@ravshansbox let's keep it open for feedback some time 👍

@3846masa said:

When sockjs/sockjs-node#247 is merged, this workaround is not necessary.

So I tested webpack-dev-server version 3.1.13 and changed
node_modules/sockjs/lib/transport.js to include origin in the ref array:

    Session.prototype.decorateConnection = function(req) {
      var address, headers, i, key, len, ref, remoteAddress, remotePort, socket, x;
      if (!(socket = this.recv.connection)) {
        socket = this.recv.response.connection;
      }
      try {
        remoteAddress = socket.remoteAddress;
        remotePort = socket.remotePort;
        address = socket.address();
      } catch (error) {
        x = error;
      }
      if (remoteAddress) {
        this.connection.remoteAddress = remoteAddress;
        this.connection.remotePort = remotePort;
        this.connection.address = address;
      }
      this.connection.url = req.url;
      this.connection.pathname = req.pathname;
      this.connection.protocol = this.recv.protocol;
      headers = {};
      ref = ['referer', 'x-client-ip', 'x-forwarded-for',
             'x-forwarded-host', 'x-forwarded-port', 'x-cluster-client-ip',
             'via', 'x-real-ip', 'x-forwarded-proto', 'x-ssl', 'dnt', 'host',
             'user-agent', 'accept-language', 'origin']; // <-- here !
      for (i = 0, len = ref.length; i < len; i++) {
        key = ref[i];
        if (req.headers[key]) {
          headers[key] = req.headers[key];
        }
      }
      if (headers) {
        return this.connection.headers = headers;
      }
    };

And it worked. Therefore I guess that if sockjs includes that small change as proposed in sockjs/sockjs-node#247, this issue would also be resolved.

god , i got the same problem and it confused me, maybe i have to roll back

@show-me-code what you have? Problem will be solved, please check you deps version and if problem exists please create minimum reproducible test repo

@carlosgeos yes, please tests 3.1.14 version, we implement workaround on our side

Yep, 3.1.14 works fine 👍

@evilebottnawi okay, now I may have to roll back to version 3.1.10

@show-me-code what? Issue was fixed in 3.1.14, if you still have problems please create minimum reproducible test repo

@evilebottnawi OH, I checked my version and find my version is 3.1.11, that's the reason caused problem , thanks a lot

Fixed in webpack-dev-server@3.1.14, please your deps before write, anyway feel free to feedback, thanks for helping

I think this fix caused another problem. I'm using webpack-dev-server@3.1.14 in 2 new projects and both show the same high severity vulnerability:

High Missing Origin Validation
Package webpack-dev-server
Patched in >=3.1.11
Dependency of webpack-dev-server [dev]
Path webpack-dev-server
More info https://nodesecurity.io/advisories/725

webpack-dev-server@3.1.14 is not fixed this issue

@SharakPL https://www.npmjs.com/advisories/725/versions says all versions are affected so I think this fix had little to do with it:

My guess is that the npm security team judged that the package still has the vulnerability. What is weird is that in their website, they say the remediation is to update to version 3.1.6 (when the "presumed" fix for the origin checking vulnerability came in 3.1.11):

And in the report of npm audit it says the patch happened in 3.1.11 but still reports it even though the package has version 3.1.14:

                      === npm audit security report ===                        
                                                                                
┌──────────────────────────────────────────────────────────────────────────────┐
│                                Manual Review                                 │
│            Some vulnerabilities require your attention to resolve            │
│                                                                              │
│         Visit https://go.npm.me/audit-guide for additional guidance          │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Missing Origin Validation                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ webpack-dev-server                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=3.1.11                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ webpack-dev-server                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ webpack-dev-server                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/725                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 high severity vulnerability in 3441 scanned packages
  1 vulnerability requires manual review. See the full report for details.

@cc616 You mean 3.1.14 has not fixed the infinite Invalid Host/Origin header message ? I think it has

Yes, it seems the npmjs security team does not know what is going on.

Reported https://npm.community/t/advisory-725-inconsistently-marks-affected-versions/4333

It happens again for me with the following versions:

{
  "webpack-cli": "3.2.0",
  "webpack-dev-server": "3.1.14"
}

Does it occur to you guys?

@davidpelayo yes, it is happening for me as well with the latest versions of both webpack-cli and webpack-dev-server

For now, I've added:

disableHostCheck: true,

...which skirts around the issue.

@khalwat >

@davidpelayo yes, it is happening for me as well with the latest versions of both webpack-cli and webpack-dev-server

For now, I've added:
disableHostCheck: true,
...which skirts around the issue.

Where could I add this disableHostCheck: true, ?

Hi, I have no problem with this minimal example (with the latest versions of webpack-cli and webpack-dev-server): https://github.com/carlosgeos/simple-webpack-repo

@mrbbm in the webpack config like this:

module.exports = {
  // ...
  devServer: {
    disableHostCheck: true
  }
  // ...
};

@carlosgeos

Hi, I have no problem with this minimal example (with the latest versions of webpack-cli and webpack-dev-server): https://github.com/carlosgeos/simple-webpack-repo

@mrbbm in the webpack config like this:
module.exports = {
  // ...
  devServer: {
    disableHostCheck: true
  }
  // ...
};

Thanks for your reply. I would like to know where could I add in my Angular 7 project, there won't be any file namely webpack.config

@mrbbm I just had that very problem after upgrading my project to angular 7.2.0. I fixed it by modifying my package.json file as so:

{
  ...
  "scripts": {
    "ng": "ng",
    "start": "ng serve --disableHostCheck=true",    <===== HERE
    "build": "ng build --extract-css",
   ...

Even with disableHostCheck now after updating I can not get rid of these errors.

Are there any chances to solve this problem soon?

If you're using @angular-builders/custom-webpack try this:

// custom-webpack.config.js
module.exports = {

  devServer: {
    disableHostCheck: true
  },

   plugins: []
};

I am running 3.11.0 webpack-dev-server and still having this problem after specifying disableHostCheck: true

I see this message consistently when I run my project via Fiddler at localhost.fiddler:4200 and not when I use localhost:4200.

This is happening now on webpack 5 and disableHostCheck is not part of the api anymore. Any thoughts?

Using webpack-dev-server 4.0.0 disableHostCheck: true is not available anymore.

headers: {
        'Access-Control-Allow-Origin': '*'
},

This is also not working

@kevinmu17 the disableHostCheck: true option was removed in favor of allowedHosts: "all", for more information please refer to our migration guide - https://github.com/webpack/webpack-dev-server/blob/master/migration-v4.md

@kevinmu17 the disableHostCheck: true option was removed in favor of allowedHosts: "all", for more information please refer to our migration guide - https://github.com/webpack/webpack-dev-server/blob/master/migration-v4.md

This link should be available on https://webpack.js.org/configuration/dev-server/ This was a live saver, I was banging my head, the information is very well explained and it took me a few hours to migrate. Thank you very much for pointing this out!