The djangosecure.middleware.SecurityMiddleware performs three different tasks for you. Each one can be independently enabled or disabled with a setting.

X-Frame-Options: DENY

Clickjacking attacks use layered frames to mislead users into clicking on a different link from the one they think they are clicking on. Fortunately, newer browsers support an X-Frame-Options header that allows you to limit or prevent the display of your pages within a frame. Valid options are “DENY” or “SAMEORIGIN” - the former prevents all framing of your site, and the latter allows only sites within the same domain to frame.

Unless you have a need for frames, your best bet is to set “X-Frame-Options: DENY” – and this is what SecurityMiddleware will do for all responses, if the SECURE_FRAME_DENY setting is True.

If you have a few pages that should be frame-able, you can set the “X-Frame-Options” header on the response to “SAMEORIGIN” in the view; SecurityMiddleware will not override an already-present “X-Frame-Options” header. If you don’t want the “X-Frame-Options” header on this view’s response at all, decorate the view with the frame_deny_exempt decorator:

from djangosecure.decorators import frame_deny_exempt

def my_view(request):
    # ...

HTTP Strict Transport Security

For sites that should only be accessed over HTTPS, you can instruct newer browsers to refuse to connect to your domain name via an insecure connection (for a given period of time) by setting the “Strict-Transport-Security” header. This reduces your exposure to some SSL-stripping man-in-the-middle (MITM) attacks.

SecurityMiddleware will set this header for you on all HTTPS responses if you set the SECURE_HSTS_SECONDS setting to a nonzero integer value.


The HSTS policy applies to your entire domain, not just the URL of the response that you set the header on. Therefore, you should only use it if your entire domain is served via HTTPS only.


Browsers properly respecting the HSTS header will refuse to allow users to bypass warnings and connect to a site with an expired, self-signed, or otherwise invalid SSL certificate. If you use HSTS, make sure your certificates are in good shape and stay that way!

SSL Redirect

If your site offers both HTTP and HTTPS connections, most users will end up with an unsecured connection by default. For best security, you should redirect all HTTP connections to HTTPS.

If you set the SECURE_SSL_REDIRECT setting to True, SecurityMiddleware will permanently (HTTP 301) redirect all HTTP connections to HTTPS.


For performance reasons, it’s preferable to do these redirects outside of Django, in a front-end loadbalancer or reverse-proxy server such as nginx. In some deployment situations this isn’t an option - SECURE_SSL_REDIRECT is intended for those cases.

If the SECURE_SSL_HOST setting has a value, all redirects will be sent to that host instead of the originally-requested host.

If there are a few pages on your site that should be available over HTTP, and not redirected to HTTPS, you can list regular expressions to match those URLs in the SECURE_REDIRECT_EXEMPT setting.


If you are deployed behind a load-balancer or reverse-proxy server, and Django can’t seem to tell when a request actually is already secure, you may need to set the SECURE_PROXY_SSL_HEADER setting.

Project Versions

Table Of Contents

Previous topic

Design Goals

Next topic

The checksecure management command

This Page