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 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 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?

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?

• javascript
• node.js
• express
• heroku

• 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 Commented Oct 8, 2016 at 8:01
• @Keith Just post that as an answer, providing backlinks, if necessary :) – hjpotter92 Commented Oct 8, 2016 at 8: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 Commented Oct 8, 2016 at 8: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 Commented Oct 8, 2016 at 9:19

1 Answer 1

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.