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.
[ "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_frame_deny", "djangosecure.check.djangosecure.check_content_type_nosniff", "djangosecure.check.djangosecure.check_xss_filter", "djangosecure.check.djangosecure.check_ssl_redirect", ]
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
Has no effect unless SECURE_HSTS_SECONDS is set to a non-zero value.
False (only for backwards compatibility; in most cases if HSTS
is used it should be set to
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.
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.
Should be a list of regular expressions. Any URL path matching a regular
expression in this list will not be redirected to HTTPS, if
True (if it is
False this setting has no
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
www.example.com). If SECURE_SSL_REDIRECT is
setting has no effect.
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.