You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered a sneaky issue today, due to theincludeSubDomain setting. I have set up a simple page, where I used your yes-https package. It mostly works like a charm, but this page is served on both a "www" subdomain and on the root domain – causing the HSTS policy to be enforced on absolutely all my subdomains. This is all fine and dandy if everything points to your apps and services, where you have set up TLS/HTTPS. On the other hand, if some of these are forwarding or redirecting to your mail provider etc. – things get more interesting.
So my question/suggestion is: Should the includeSubDomain setting default to false? This issue might be caused by a suboptimal setup of my web app and domain. But I suspect this is not an uncommon scenario around the web. And I had to use quite a few brain cycles to find the culprit. So in my mind it make more sense to explicitly ask to enforce the HSTS policy on all sub domains.
Any thoughts?
The text was updated successfully, but these errors were encountered:
Apologies for any trouble this may have caused. I'd generally prefer to keep the "more secure by default" approach we have here now. Generally, I'd expect more users to want coverage over their own domain and subdomains rather than a limited scope. It's entirely possible I'm wrong :) I'd rather someone get tripped up during initial configuration by being too secure, rather than being lax by default and having someone find out they weren't protected.
No worries :) Had I read the documentation, I would have picked up on this. In the end I learned more about HSTS – which is a good thing.
This makes sense, and in most cases I would agree that the "secure by default" approach is preferred. In this case, I would argue that an explicit approach may be favorable. By defaulting to to including all the subdomains, we make an assumption that all domains/subdomains are handled by the respective web app. Doing so, I feel that we are giving more responsibility to the app than it I should have. And if all subdomains aren't set up and configured for https, you will experience strange side effects – which are not very obvious, and hard to debug.
What I'm getting at, is that the web app shouldn't enforce settings for subdomains not served by itself. Especially when this setting comes with requirements/dependencies that needs to be met, and aren't provide by the yes-https package.
Anyways, this is mostly nitpicking – and it also possible that I'm wrong :)
Hi!
I encountered a sneaky issue today, due to the
includeSubDomain
setting. I have set up a simple page, where I used your yes-https package. It mostly works like a charm, but this page is served on both a "www" subdomain and on the root domain – causing the HSTS policy to be enforced on absolutely all my subdomains. This is all fine and dandy if everything points to your apps and services, where you have set up TLS/HTTPS. On the other hand, if some of these are forwarding or redirecting to your mail provider etc. – things get more interesting.So my question/suggestion is: Should the
includeSubDomain
setting default tofalse
? This issue might be caused by a suboptimal setup of my web app and domain. But I suspect this is not an uncommon scenario around the web. And I had to use quite a few brain cycles to find the culprit. So in my mind it make more sense to explicitly ask to enforce the HSTS policy on all sub domains.Any thoughts?
The text was updated successfully, but these errors were encountered: