redirect HTTP to HTTPS unless explicitly instructed not to do this re…

[jweismann]

Sorry Pieter. This one totally slipped my mind until I saw all the activity today. I did simple tests on heroku via curl, cf. below and the 6 cases shown below worked as expected:

heroku config:unset -a hostname INSECURE_USE_HTTP
curl -Ls -w %{url_effective} -o /dev/null http://hostname.herokuapp.com
curl -Ls -w %{url_effective} -o /dev/null https://hostname.herokuapp.com
heroku config:set -a hostname INSECURE_USE_HTTP=true
heroku config --app hostname | grep INSECURE
curl -Ls -w %{url_effective} -o /dev/null http://hostname.herokuapp.com
curl -Ls -w %{url_effective} -o /dev/null https://hostname.herokuapp.com
heroku config:set -a hostname INSECURE_USE_HTTP=false
heroku config --app hostname | grep INSECURE
curl -Ls -w %{url_effective} -o /dev/null http://hostname.herokuapp.com
curl -Ls -w %{url_effective} -o /dev/null https://hostname.herokuapp.com

Would you like the feature added to app.json too ? Is the default as you like or should default be to behave as current implementation ?

[jweismann]

@PieterGit

I am not sure if you aimed at HSTS only and prefer not to use helmet, cf. https://github.com/helmetjs/helmet but with helmet it seems that we can harden HTTP headers (not just HSTS) in a consistent way w/o too much local code maintenance. If you had something else in mind regarding your HSTS proposal, please let me know.

There are still a few security headers that we can harden: Content-Security-Policy, Referrer-Policy and Feature-Policy so I will have a look at those now but we went from F to B in https://securityheaders.com with the present PR.

PS! I did test the resulting headers with (under different config settings):
curl -I https://hostname.herokuapp.com

[PieterGit]

@jweismann no problem in using helmet and doing stuff more secure. If you integrate helmet, please also have a look at our CORS options, see https://github.com/nightscout/cgm-remote-monitor#cors-cors
I will review and test this PR later. Perhaps @sulkaharo can also have a look.

[sulkaharo]

@jweismann How extensively have you tested this? Wondering if helmet will have any side-effects on the REST API

+1 for this though, just need to make sure nothing breaks

[jweismann]

@sulkaharo. The tests I did beside the raw curl calls confines itself to use it, i.e. I have not experienced problems with the browser versions that we use on our ordinary usage of the site but that is not a solid test (I have no clue as to how others use NS and which browsers and which versions ought to be supported, i.e. what do we define as proper test coverage here?).

My thoughts was to have this as an optional feature (and off by default) so if one experience an issue with this then one can just revert to the default settings. The setting 'SECURE_HTTP_HEADERS' is off by default so to use the hardening provided by helmet one will actively have to change this setting.

Please take note that @PieterGit requestd two PRs. The first with the auto redirections from HTTP to HTTPS (redirections should be on by default as req. by @PieterGit ). The latter PR was to address his wish to support HSTS and I aimed at a solution with minimal maintenance and hence suggested to use helmet instead of explicit support which also harden headers beyond HSTS and we could even harden it further if you like. I was awaiting some feedback on this idea. Thanks for getting back!

[PieterGit]

@jweismann You can do testing with the inbuilt swagger, see /api-docs.html on your Nightscout. PR looks good to me, but I haven't had time to do some testing. If others want to test, we can already merge this PR. More helmet features (e.g. CORS) can be included in another PR.

[PieterGit]

Tested api's with token. No problem. Also oref0 rigs runs fine with these headers.

[PieterGit]

I made some improvements to the helmet implementation in this PR
#4091

[jweismann]

Hi Pieter,

Sorry for the radio silence. I checked the upstream code today and found that a change was made to the logic and to me it seems that this change implies that the redirections no longer work. I reverted the logic and this made the redirections work again. Tested on heroku with curl:

curl -Ls -w %{url_effective} -o /dev/null http://site.herokuapp.com

with upstream dev does not redirect but stick to http://site.herokuapp.com

Then I changed back:

-// if (!process.env.INSECURE_USE_HTTP=='true') {
if (process.env.INSECURE_USE_HTTP !== 'true') {

and

curl -Ls -w %{url_effective} -o /dev/null http:site.herokuapp.com

now redirect to https://site.herokuapp.com.

Moreover, with

heroku config:set -a SITE INSECURE_USE_HTTP=true

the redirections no longer happens - again as expected.