13

I was needed to redirect http to https and found this code:

app.enable('trust proxy');
app.use((req, res, next) => {
    if (req.secure) {
        next();
    } else {
        res.redirect('https://' + req.headers.host + req.url);
    }
});

I'm using heroku to host my project, I noticed that heroku as default issued *.herokuapp.com cert, so I can use http and https as well.

When looked at req.secure within app.use callback, without app.enable('trust proxy'), req.secure is always false, when I add app.enable('trust proxy') it's false for about 2 times and after the https redirection it's switches to true.

app.enable('trust proxy'), the docs:

Indicates the app is behind a front-facing proxy, and to use the X-Forwarded-* headers to determine the connection and the IP address of the client.

My question:

Why would my server be behind a proxy?(is it relates to the issued *.herokuapp.com cert?), if someone could explain how all fits together, I mean, why my server is behind a proxy? and why without app.enable express won't identify(or accept) secure connection?

Aviel Fedida
  • 4,004
  • 9
  • 54
  • 88
  • 2
    If your not running behind a proxy, it's not required. Eg, if your running multiple websites on a server, chances are your using a Proxy. X-Forwarded-For header attributes get added when doing this so that your proxy can see what the original url was, proxying in the end will be going to localhost you see. The reason why it's needed is that X-Forwared-For can be faked, there is nothing stopping the client adding these too, not just a proxy. So trust-proxy should only be enabled on the receiving end, that would be behind your firewall. Because you have control, you cant trust. – Keith Oct 08 '16 at 08:01
  • @Keith Just post that as an answer, providing backlinks, if necessary :) – hjpotter92 Oct 08 '16 at 08:14
  • @Keith you should really post it an answer so I can accept it, btw, the reason why `req.secure` is being `false` without `app.enable('trust proxy')` is that internally(behind the firewall) between the proxy and the my server the communication is not secured? – Aviel Fedida Oct 08 '16 at 08:51
  • @AvielFedida Ok, done. I do all my SSL on my Reverse Proxy nowadays and force SSL, as google will rank's SSL better too. So I never really need to check req.secure, as I basically have a full redirect on port http:80 -> https:443. Another reason I do it on the reverse proxy is also for performance, it allows the reverse proxy to handle encryption and my express server doesn't then need too. – Keith Oct 08 '16 at 09:19

1 Answers1

23

If your not running behind a proxy, it's not required. Eg, if your running multiple websites on a server, chances are your using a Proxy.

X-Forwarded-For header attributes get added when doing this so that your proxy can see what the original url was, proxying in the end will be going to localhost you see. The reason why it's needed is that X-Forwared-For can be faked, there is nothing stopping the client adding these too, not just a proxy. So trust-proxy should only be enabled on the receiving end, that would be behind your firewall. Because you have control, you can trust this.

So in a nutshell, if your website is running behind a proxy, you can enable it. If you website is running direct on port 80, you don't want to trust it. As the sender could pretend to be coming from localhost etc.

Keith
  • 22,005
  • 2
  • 27
  • 44