Question: Reasons for validating path and secure options

This is more of an a question rather than issue. From my casual reading of the source code, it looks like express-session will validate path and protocol in incoming request if those options are used. https://github.com/expressjs/session/blob/6a128cc5941365d0416d92760328a8e11549eb5d/index.js#L623 https://github.com/expressjs/session/blob/6a128cc5941365d0416d92760328a8e11549eb5d/index.js#L196

My question is is there any valid reason to do this given that browser will only send cookie if all condition are met anyway?

Context

• Regarding secure option, in many applications ssl termination happens in reverse proxy or load balancer, so incoming request to express server is http. I understand this issue can be avoided by setting x-forwarded-proto header, so its not a big problem now.

• Regarding cookie path, our reverse proxy (nginx) rewrites path to backend server, so the original request path from browser and and the path in incoming request to express server are different. Can I ask if there is any way to solve this? Also incase we need to update path in future, does that mean all users need to be logged out ?

[dougwilson]

Also incase we need to update path in future, does that mean all users need to be logged out ?

You cannot change the path of an already set cookie; this is a web browser limitation, as the path of a cookie is part of the keying (which includes the cookie name), so you will effectively have two cookies with the same name in the web browser. In order to change the path of an existing cookie, you must first delete the cookie from the browser that is set on the old path and then create a new cookie with the new path.

[dougwilson]

Hi, sorry you haven’t gotten an answer yet. The issue is that letting the browser check this means that your “secure” cookie is only secure in a single direction (from the client to the endpoint it connects to). There are issues of in-the-wild misconfigurations that accidentally expose a web server over both http and https. When a web browser goes to yoursite.com over http, the session cookie will be sent back in the clear on accident, nullifying almost all the protection a security cookie grants – it could have been observed over the unencrypted channel on the way from the server to the client.

Because of this issue, the cookie specs use “SHOULD” in that servers should not send a secure cookie over an unencrypted connection. This module implements that part by performing these checks – not only that, but when we were not doing this, a security research company brought this to our attention as a security vulnerability!

As such, we cannot remove the check without ending up just blacklisted as an “insecure” npm module by these security companies, sorry to say.

The best course of action is the following:

1. Implement a security channel over your entire communications path (the current industry best practice)
2. Ensure you are correctly handling things like x-forwarded-proto if you are following the previous generation practice of tls termination / stripping at a gateway.
3. Just tell Express req.protocol is always https (Object.define(app.request, 'protocol', { value: 'https' })) or something similar.
4. Use a different module that is not under such scrutiny of security auditing companies which does not implement such a check.