Add support for including a Strict-Transport-Security header (for use only when a proxy or load balancer is handling TLS/SSL) (was PR # 85 for drdrew42 repo)

[taniwallach]

Same as drdrew42#85

---

Add support for including a Strict-Transport-Security header.

This header is meant to force browsers to only contact site via TLS/SSL ("https"). Using this header is a commonly recommended security practice, but is dangerous should the site have any need to work over plain (port 80) HTTP.

The value for the header is provided in render.conf as a string value called HSTS_HEADER, and when that value is not provided (or is false for Perl purposes) no Strict-Transport-Security header will be set.

No default value is being provided in render.conf.dist so the header will not be enabled by accident.

The header should only be used on a server which is available via a proxy or load balancer which has a valid SSL certificate and handles the TLS/SSL level (and which will continue to do so for the long-term).

Note: It could be that some proxy setups could add the header at the proxy, but the AWS Elastic Application Load Balancer does not have the option to add this header, but can provide SSL termination, so the header needs to be added on the "back end" (in our case the Standalone renderer).

[drgrice1]

Rather than adding a separate before_dispatch hook to the CORS settings, just use the same hook. We don't want a bunch of separate hooks like this. Although, I don't think either of these belong in the renderer code. This is something that should be set by the proxy.

[taniwallach]

I'm not using a proxy. The renderer seems to work reasonably well without one, and in my use case is behind an AWS application load balancer which does SSL offloading.

[drgrice1]

You should be running hypnotoad behind some sort of proxy. In any case, see my later comment.

[drgrice1]

I think that what would be best here, rather than adding a hook and config setting for each possible header that someone might want to add, would be to add a single config array of headers and a single hook that sets any that are in that array. Previously you added the CORS header, and now you are adding this particular security header. Someone else might want another header, and decide to add another setting in the conf file and another hook. That just doesn't make sense, and we can't predict what custom headers someone might want. So if we make a general config array that someone can add any header they want to, and implement a single hook to add any headers therein it will be more versatile, and won't require changing the config file structure and code any further.

[taniwallach]

I think that what would be best here, rather than adding a hook and config setting for each possible header that someone might want to add, would be to add a single config array of headers and a single hook that sets any that are in that array. Previously you added the CORS header, and now you are adding this particular security header. Someone else might want another header, and decide to add another setting in the conf file and another hook. That just doesn't make sense, and we can't predict what custom headers someone might want. So if we make a general config array that someone can add any header they want to, and implement a single hook to add any headers therein it will be more versatile, and won't require changing the config file structure and code any further.

I think that is a very good idea. I will try to implement such an approach.