#1, good call!
#2, usually I am 100% in agreement. But referer vs referrer in the HTTP spec is a special case. I chose to do this as referer is misspelled in the spec itself.
If both keys exist, then it’s an even bigger signal of user mistake. Are you going to fail then? Distinction becomes pretty arbitrary.
As a user, I’d rather have a failure at boot time if I got it wrong. Just because I had a typo once doesn’t mean I always make it. What if I tried to transform my own config? I’d have to follow special case your referers property like you did to keep it consistent.
Neat, thanks for raising awareness of this issue. I don't think it makes a lot of sense for the web server case (as you said, using TLS would fix it and that seems like the bigger concern), but if someone is building something like an electron app with a local server component then they ought to use this.
FWIW I think you can check just the Host header, it's always going to be present and can't be set by an attacker - referrer doesn't add anything extra and attackers can force requests with blank referrers.
Also all your example regexes are correctly anchored but I can see a developer shooting themselves in the foot with that - I'd maybe add some warnings around it or even programmatically enforce anchored regexes.
I understand validating the `Host` header but my understanding that the referer field is optional and theres quite a few users who either block referer headers for privacy/anti-tracking purposes. Would this stop those users from accessing the site also?
Then this: https://github.com/brannondorsey/host-validation/blob/2ba467... is not something I would recommend. Don't try to fix bad input.