Settings Reference

SECURE_CHECKS

A list of strings. Each string should be a Python dotted path to a function implementing a configuration check that will be run by the checksecure management command.

Defaults to:

[
    "djangosecure.check.csrf.check_csrf_middleware",
    "djangosecure.check.sessions.check_session_cookie_secure",
    "djangosecure.check.sessions.check_session_cookie_httponly",
    "djangosecure.check.djangosecure.check_security_middleware",
    "djangosecure.check.djangosecure.check_sts",
    "djangosecure.check.djangosecure.check_sts_include_subdomains",
    "djangosecure.check.djangosecure.check_frame_deny",
    "djangosecure.check.djangosecure.check_content_type_nosniff",
    "djangosecure.check.djangosecure.check_xss_filter",
    "djangosecure.check.djangosecure.check_ssl_redirect",
    "djangosecure.check.djangosecure.check_secret_key",
]

SECURE_FRAME_DENY

Note

Django 1.4+ provides the same functionality via the X_FRAME_OPTIONS setting and XFrameOptionsMiddleware. You can use either this setting or Django’s, there’s no value in using both.

If set to True, causes SecurityMiddleware to set the X-Frame-Options: DENY header on all responses that do not already have that header (and where the view was not decorated with the frame_deny_exempt decorator).

Defaults to False.

SECURE_HSTS_SECONDS

If set to a non-zero integer value, causes SecurityMiddleware to set the HTTP Strict Transport Security header on all responses that do not already have that header.

Defaults to 0.

SECURE_HSTS_INCLUDE_SUBDOMAINS

If True, causes SecurityMiddleware to add the includeSubDomains tag to the HTTP Strict Transport Security header.

Has no effect unless SECURE_HSTS_SECONDS is set to a non-zero value.

Defaults to False (only for backwards compatibility; in most cases if HSTS is used it should be set to True).

SECURE_CONTENT_TYPE_NOSNIFF

If set to True, causes SecurityMiddleware to set the X-Content-Type-Options: nosniff header on all responses that do not already have that header.

Defaults to False.

SECURE_BROWSER_XSS_FILTER

If set to True, causes SecurityMiddleware to set the X-XSS-Protection: 1; mode=block header on all responses that do not already have that header.

Defaults to False.

SECURE_PROXY_SSL_HEADER

Note

This setting is built-in to Django 1.4+. The Django setting works identically to this version.

A tuple of (“header”, “value”); if “header” is set to “value” in request.META, django-secure will tell Django to consider this a secure request. For example:

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTOCOL", "https")

See Detecting proxied SSL for more details.

Defaults to None.

Warning

If you set this to a header that your proxy allows through from the request unmodified (i.e. a header that can be spoofed), you are allowing an attacker to pretend that any request is secure, even if it is not. Make sure you only use a header that your proxy sets unconditionally, overriding any value from the request.

SECURE_REDIRECT_EXEMPT

Should be a list of regular expressions. Any URL path matching a regular expression in this list will not be redirected to HTTPS, if SECURE_SSL_REDIRECT is True (if it is False this setting has no effect).

Defaults to [].

SECURE_SSL_HOST

If set to a string (e.g. secure.example.com), all SSL redirects will be directed to this host rather than the originally-requested host (e.g. www.example.com). If SECURE_SSL_REDIRECT is False, this setting has no effect.

Defaults to None.

SECURE_SSL_REDIRECT

If set to True, causes SecurityMiddleware to redirect all non-HTTPS requests to HTTPS (except for those URLs matching a regular expression listed in SECURE_REDIRECT_EXEMPT).

Note

If turning this to True causes infinite redirects, it probably means your site is running behind a proxy and can’t tell which requests are secure and which are not. Your proxy likely sets a header to indicate secure requests; you can correct the problem by finding out what that header is and configuring the SECURE_PROXY_SSL_HEADER setting accordingly.

Defaults to False.