Double 'Strict-Transport-Security' headers set if the wrapped WGSI app sets it

[edmorley]

We currently use Django+WhiteNoise, wrapped with wsgi-sslify. ie:

from django.core.wsgi import get_wsgi_application as django_app
from wsgi_sslify import sslify

application = CustomWhiteNoise(django_app())
application = sslify(application)

We cannot rely on Django's security middleware on it's own (which would redirect to HTTPS and set the HSTS header), since some requests are served by WhiteNoise and so are never seen by Django - which is why we use wgsi-sslify, as recommended in evansd/whitenoise#53.

However if Django has its SECURE_HSTS_SECONDS setting set to a value other than the default of zero, then it sets an HSTS header itself.

This means that whilst for requests served by WhiteNoise we correctly get just one header (added by wsgi-sslify):

$ curl -Is "http://localhost/" -H 'X-FORWARDED-PROTO: https' | grep -i strict
Strict-Transport-Security: max-age=31536000

...for those served by Django (where in the case of this example, SECURE_HSTS_SECONDS has been set to 999), we now get double headers:

$ curl -Is "http://localhost/api/" -H 'X-FORWARDED-PROTO: https' | grep -i strict
strict-transport-security: max-age=999
Strict-Transport-Security: max-age=31536000

One solution would be to just not set SECURE_HSTS_SECONDS in Django's config, however that causes warnings when using Django's deployment best practices self-check (./manage.py check --deploy).

These could be suppressed, however I wonder if a more correct fix would be to have wgsi-sslify only add the HSTS header if it's not already set (albeit varying capitalisation would have to be handled), in: https://github.com/jacobian/wsgi-sslify/blob/c2d25e5cb735029d7f1f37af8ad9d30988373f89/wsgi_sslify.py#L23

This would be similar to what Django does itself in its security middleware: https://github.com/django/django/blob/1.9.1/django/middleware/security.py#L29

...and would possibly help others using wsgi-sslify who either don't realise their app is already setting HSTS headers, or who similarly use a combination of WGSI apps, some of which set the HSTS header and some not.

This may just be wontfix, but I'd thought I'd file in case this wasn't intended behaviour :-)