p15693087
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Alphabetized system check reference.

This commit is contained in:
Tim Graham 2017-01-04 19:53:23 -05:00
parent 0793182694
commit ab661e994b
1 changed files with 261 additions and 266 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

527
docs/ref/checks.txt
View File

@ -11,7 +11,7 @@ The framework is extensible so you can easily add your own checks.
For details on how to add your own checks and integrate them with Django's For details on how to add your own checks and integrate them with Django's
system checks, see the :doc:`System check topic guide </topics/checks>`. system checks, see the :doc:`System check topic guide </topics/checks>`.
API Reference API reference
============= =============
``CheckMessage`` ``CheckMessage``
@ -66,88 +66,81 @@ class name.
.. class:: Error(msg, hint=None, obj=None, id=None) .. class:: Error(msg, hint=None, obj=None, id=None)
.. class:: Critical(msg, hint=None, obj=None, id=None) .. class:: Critical(msg, hint=None, obj=None, id=None)
Builtin checks
==============
.. _system-check-builtin-tags: .. _system-check-builtin-tags:
Builtin tags Builtin tags
------------ ============
Django's system checks are organized using the following tags: Django's system checks are organized using the following tags:
* ``models``: Checks governing model, field and manager definitions.
* ``signals``: Checks on signal declarations and handler registrations.
* ``admin``: Checks of any admin site declarations. * ``admin``: Checks of any admin site declarations.
* ``compatibility``: Flagging potential problems with version upgrades.
* ``security``: Checks security related configuration.
* ``templates``: Checks template related configuration.
* ``caches``: Checks cache related configuration. * ``caches``: Checks cache related configuration.
* ``urls``: Checks URL configuration. * ``compatibility``: Flags potential problems with version upgrades.
* ``database``: Checks database-related configuration issues. Database checks * ``database``: Checks database-related configuration issues. Database checks
are not run by default because they do more than static code analysis as are not run by default because they do more than static code analysis as
regular checks do. They are only run by the :djadmin:`migrate` command or if regular checks do. They are only run by the :djadmin:`migrate` command or if
you specify the ``database`` tag when calling the :djadmin:`check` command. you specify the ``database`` tag when calling the :djadmin:`check` command.
* ``models``: Checks of model, field, and manager definitions.
.. versionadded:: 1.10 * ``security``: Checks security related configuration.
* ``signals``: Checks on signal declarations and handler registrations.
The ``database`` tag was added. * ``templates``: Checks template related configuration.
* ``urls``: Checks URL configuration.
Some checks may be registered with multiple tags. Some checks may be registered with multiple tags.
Core system checks Core system checks
------------------ ==================
Models Backwards compatibility
~~~~~~ -----------------------
* **models.E001**: ``<swappable>`` is not of the form ``app_label.app_name``. The following checks are performed to warn the user of any potential problems
* **models.E002**: ``<SETTING>`` references ``<model>``, which has not been that might occur as a result of a version upgrade.
installed, or is abstract.
* **models.E003**: The model has two many-to-many relations through the
intermediate model ``<app_label>.<model>``.
* **models.E004**: ``id`` can only be used as a field name if the field also
sets ``primary_key=True``.
* **models.E005**: The field ``<field name>`` from parent model ``<model>``
clashes with the field ``<field name>`` from parent model ``<model>``.
* **models.E006**: The field clashes with the field ``<field name>`` from model
``<model>``.
* **models.E007**: Field ``<field name>`` has column name ``<column name>``
that is used by another field.
* **models.E008**: ``index_together`` must be a list or tuple.
* **models.E009**: All ``index_together`` elements must be lists or tuples.
* **models.E010**: ``unique_together`` must be a list or tuple.
* **models.E011**: All ``unique_together`` elements must be lists or tuples.
* **models.E012**: ``index_together/unique_together`` refers to the
non-existent field ``<field name>``.
* **models.E013**: ``index_together/unique_together`` refers to a
``ManyToManyField`` ``<field name>``, but ``ManyToManyField``\s are not
supported for that option.
* **models.E014**: ``ordering`` must be a tuple or list (even if you want to
order by only one field).
* **models.E015**: ``ordering`` refers to the non-existent field
``<field name>``.
* **models.E016**: ``index_together/unique_together`` refers to field
``<field_name>`` which is not local to model ``<model>``.
* **models.E017**: Proxy model ``<model>`` contains model fields.
* **models.E018**: Autogenerated column name too long for field ``<field>``.
Maximum length is ``<maximum length>`` for database ``<alias>``.
* **models.E019**: Autogenerated column name too long for M2M field
``<M2M field>``. Maximum length is ``<maximum length>`` for database
``<alias>``.
* **models.E020**: The ``<model>.check()`` class method is currently overridden.
* **models.E021**: ``ordering`` and ``order_with_respect_to`` cannot be used
together.
* **models.E022**: ``<function>`` contains a lazy reference to
``<app label>.<model>``, but app ``<app label>`` isn't installed or
doesn't provide model ``<model>``.
* **models.E023**: The model name ``<model>`` cannot start or end with an
underscore as it collides with the query lookup syntax.
* **models.E024**: The model name ``<model>`` cannot contain double underscores
as it collides with the query lookup syntax.
Fields * **1_6.W001**: Some project unit tests may not execute as expected. *This
~~~~~~ check was removed in Django 1.8 due to false positives*.
* **1_6.W002**: ``BooleanField`` does not have a default value. *This
check was removed in Django 1.8 due to false positives*.
* **1_7.W001**: Django 1.7 changed the global defaults for the
``MIDDLEWARE_CLASSES.``
``django.contrib.sessions.middleware.SessionMiddleware``,
``django.contrib.auth.middleware.AuthenticationMiddleware``, and
``django.contrib.messages.middleware.MessageMiddleware`` were removed from
the defaults. If your project needs these middleware then you should
configure this setting. *This check was removed in Django 1.9*.
* **1_8.W001**: The standalone ``TEMPLATE_*`` settings were deprecated in
Django 1.8 and the :setting:`TEMPLATES` dictionary takes precedence. You must
put the values of the following settings into your defaults ``TEMPLATES``
dict: ``TEMPLATE_DIRS``, ``TEMPLATE_CONTEXT_PROCESSORS``, ``TEMPLATE_DEBUG``,
``TEMPLATE_LOADERS``, ``TEMPLATE_STRING_IF_INVALID``.
* **1_10.W001**: The ``MIDDLEWARE_CLASSES`` setting is deprecated in Django
1.10 and the :setting:`MIDDLEWARE` setting takes precedence. Since you've
set ``MIDDLEWARE``, the value of ``MIDDLEWARE_CLASSES`` is ignored.
Caches
------
The following checks verify that your :setting:`CACHES` setting is correctly
configured:
* **caches.E001**: You must define a ``'default'`` cache in your
:setting:`CACHES` setting.
Database
--------
MySQL
~~~~~
If you're using MySQL, the following checks will be performed:
* **mysql.E001**: MySQL does not allow unique ``CharField``\s to have a
``max_length`` > 255.
* **mysql.W002**: MySQL Strict Mode is not set for database connection
'<alias>'. See also :ref:`mysql-sql-mode`.
Model fields
------------
* **fields.E001**: Field names must not end with an underscore. * **fields.E001**: Field names must not end with an underscore.
* **fields.E002**: Field names must not contain ``"__"``. * **fields.E002**: Field names must not contain ``"__"``.
@ -183,7 +176,7 @@ Fields
* **fields.W901**: ``CommaSeparatedIntegerField`` has been deprecated. Support * **fields.W901**: ``CommaSeparatedIntegerField`` has been deprecated. Support
for it (except in historical migrations) will be removed in Django 2.0. for it (except in historical migrations) will be removed in Django 2.0.
File Fields File fields
~~~~~~~~~~~ ~~~~~~~~~~~
* **fields.E200**: ``unique`` is not a valid argument for a ``FileField``. * **fields.E200**: ``unique`` is not a valid argument for a ``FileField``.
@ -193,7 +186,7 @@ File Fields
path, not an absolute path. path, not an absolute path.
* **fields.E210**: Cannot use ``ImageField`` because Pillow is not installed. * **fields.E210**: Cannot use ``ImageField`` because Pillow is not installed.
Related Fields Related fields
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
* **fields.E300**: Field defines a relation with model ``<model>``, which is * **fields.E300**: Field defines a relation with model ``<model>``, which is
@ -261,41 +254,211 @@ Related Fields
* **fields.W343**: ``limit_choices_to`` has no effect on ``ManyToManyField`` * **fields.W343**: ``limit_choices_to`` has no effect on ``ManyToManyField``
with a ``through`` model. with a ``through`` model.
Models
------
* **models.E001**: ``<swappable>`` is not of the form ``app_label.app_name``.
* **models.E002**: ``<SETTING>`` references ``<model>``, which has not been
installed, or is abstract.
* **models.E003**: The model has two many-to-many relations through the
intermediate model ``<app_label>.<model>``.
* **models.E004**: ``id`` can only be used as a field name if the field also
sets ``primary_key=True``.
* **models.E005**: The field ``<field name>`` from parent model ``<model>``
clashes with the field ``<field name>`` from parent model ``<model>``.
* **models.E006**: The field clashes with the field ``<field name>`` from model
``<model>``.
* **models.E007**: Field ``<field name>`` has column name ``<column name>``
that is used by another field.
* **models.E008**: ``index_together`` must be a list or tuple.
* **models.E009**: All ``index_together`` elements must be lists or tuples.
* **models.E010**: ``unique_together`` must be a list or tuple.
* **models.E011**: All ``unique_together`` elements must be lists or tuples.
* **models.E012**: ``index_together/unique_together`` refers to the
non-existent field ``<field name>``.
* **models.E013**: ``index_together/unique_together`` refers to a
``ManyToManyField`` ``<field name>``, but ``ManyToManyField``\s are not
supported for that option.
* **models.E014**: ``ordering`` must be a tuple or list (even if you want to
order by only one field).
* **models.E015**: ``ordering`` refers to the non-existent field
``<field name>``.
* **models.E016**: ``index_together/unique_together`` refers to field
``<field_name>`` which is not local to model ``<model>``.
* **models.E017**: Proxy model ``<model>`` contains model fields.
* **models.E018**: Autogenerated column name too long for field ``<field>``.
Maximum length is ``<maximum length>`` for database ``<alias>``.
* **models.E019**: Autogenerated column name too long for M2M field
``<M2M field>``. Maximum length is ``<maximum length>`` for database
``<alias>``.
* **models.E020**: The ``<model>.check()`` class method is currently overridden.
* **models.E021**: ``ordering`` and ``order_with_respect_to`` cannot be used
together.
* **models.E022**: ``<function>`` contains a lazy reference to
``<app label>.<model>``, but app ``<app label>`` isn't installed or
doesn't provide model ``<model>``.
* **models.E023**: The model name ``<model>`` cannot start or end with an
underscore as it collides with the query lookup syntax.
* **models.E024**: The model name ``<model>`` cannot contain double underscores
as it collides with the query lookup syntax.
Security
--------
The security checks do not make your site secure. They do not audit code, do
intrusion detection, or do anything particularly complex. Rather, they help
perform an automated, low-hanging-fruit checklist. They help you remember the
simple things that improve your site's security.
Some of these checks may not be appropriate for your particular deployment
configuration. For instance, if you do your HTTP to HTTPS redirection in a load
balancer, it'd be irritating to be constantly warned about not having enabled
:setting:`SECURE_SSL_REDIRECT`. Use :setting:`SILENCED_SYSTEM_CHECKS` to
silence unneeded checks.
The following checks are run if you use the :option:`check --deploy` option:
* **security.W001**: You do not have
:class:`django.middleware.security.SecurityMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES` so the :setting:`SECURE_HSTS_SECONDS`,
:setting:`SECURE_CONTENT_TYPE_NOSNIFF`, :setting:`SECURE_BROWSER_XSS_FILTER`,
and :setting:`SECURE_SSL_REDIRECT` settings will have no effect.
* **security.W002**: You do not have
:class:`django.middleware.clickjacking.XFrameOptionsMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, so your pages will not be served with an
``'x-frame-options'`` header. Unless there is a good reason for your
site to be served in a frame, you should consider enabling this
header to help prevent clickjacking attacks.
* **security.W003**: You don't appear to be using Django's built-in cross-site
request forgery protection via the middleware
(:class:`django.middleware.csrf.CsrfViewMiddleware` is not in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`). Enabling the middleware is the safest
approach to ensure you don't leave any holes.
* **security.W004**: You have not set a value for the
:setting:`SECURE_HSTS_SECONDS` setting. If your entire site is served only
over SSL, you may want to consider setting a value and enabling :ref:`HTTP
Strict Transport Security <http-strict-transport-security>`. Be sure to read
the documentation first; enabling HSTS carelessly can cause serious,
irreversible problems.
* **security.W005**: You have not set the
:setting:`SECURE_HSTS_INCLUDE_SUBDOMAINS` setting to ``True``. Without this,
your site is potentially vulnerable to attack via an insecure connection to a
subdomain. Only set this to ``True`` if you are certain that all subdomains of
your domain should be served exclusively via SSL.
* **security.W006**: Your :setting:`SECURE_CONTENT_TYPE_NOSNIFF` setting is not
set to ``True``, so your pages will not be served with an
``'x-content-type-options: nosniff'`` header. You should consider enabling
this header to prevent the browser from identifying content types incorrectly.
* **security.W007**: Your :setting:`SECURE_BROWSER_XSS_FILTER` setting is not
set to ``True``, so your pages will not be served with an
``'x-xss-protection: 1; mode=block'`` header. You should consider enabling
this header to activate the browser's XSS filtering and help prevent XSS
attacks.
* **security.W008**: Your :setting:`SECURE_SSL_REDIRECT` setting is not set to
``True``. Unless your site should be available over both SSL and non-SSL
connections, you may want to either set this setting to ``True`` or configure
a load balancer or reverse-proxy server to redirect all connections to HTTPS.
* **security.W009**: Your :setting:`SECRET_KEY` has less than 50 characters or
less than 5 unique characters. Please generate a long and random
``SECRET_KEY``, otherwise many of Django's security-critical features will be
vulnerable to attack.
* **security.W010**: You have :mod:`django.contrib.sessions` in your
:setting:`INSTALLED_APPS` but you have not set
:setting:`SESSION_COOKIE_SECURE` to ``True``. Using a secure-only session
cookie makes it more difficult for network traffic sniffers to hijack user
sessions.
* **security.W011**: You have
:class:`django.contrib.sessions.middleware.SessionMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but you have not set
:setting:`SESSION_COOKIE_SECURE` to ``True``. Using a secure-only session
cookie makes it more difficult for network traffic sniffers to hijack user
sessions.
* **security.W012**: :setting:`SESSION_COOKIE_SECURE` is not set to ``True``.
Using a secure-only session cookie makes it more difficult for network traffic
sniffers to hijack user sessions.
* **security.W013**: You have :mod:`django.contrib.sessions` in your
:setting:`INSTALLED_APPS`, but you have not set
:setting:`SESSION_COOKIE_HTTPONLY` to ``True``. Using an ``HttpOnly`` session
cookie makes it more difficult for cross-site scripting attacks to hijack user
sessions.
* **security.W014**: You have
:class:`django.contrib.sessions.middleware.SessionMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but you have not set
:setting:`SESSION_COOKIE_HTTPONLY` to ``True``. Using an ``HttpOnly`` session
cookie makes it more difficult for cross-site scripting attacks to hijack user
sessions.
* **security.W015**: :setting:`SESSION_COOKIE_HTTPONLY` is not set to ``True``.
Using an ``HttpOnly`` session cookie makes it more difficult for cross-site
scripting attacks to hijack user sessions.
* **security.W016**: :setting:`CSRF_COOKIE_SECURE` is not set to ``True``.
Using a secure-only CSRF cookie makes it more difficult for network traffic
sniffers to steal the CSRF token.
* **security.W017**: :setting:`CSRF_COOKIE_HTTPONLY` is not set to ``True``.
Using an ``HttpOnly`` CSRF cookie makes it more difficult for cross-site
scripting attacks to steal the CSRF token. *This check is removed in Django
1.11 as the* :setting:`CSRF_COOKIE_HTTPONLY` *setting offers no pratical
benefit.*
* **security.W018**: You should not have :setting:`DEBUG` set to ``True`` in
deployment.
* **security.W019**: You have
:class:`django.middleware.clickjacking.XFrameOptionsMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but :setting:`X_FRAME_OPTIONS` is not set to
``'DENY'``. The default is ``'SAMEORIGIN'``, but unless there is a good reason
for your site to serve other parts of itself in a frame, you should change
it to ``'DENY'``.
* **security.W020**: :setting:`ALLOWED_HOSTS` must not be empty in deployment.
* **security.W021**: You have not set the
:setting:`SECURE_HSTS_PRELOAD` setting to ``True``. Without this, your site
cannot be submitted to the browser preload list.
Signals Signals
~~~~~~~ -------
* **signals.E001**: ``<handler>`` was connected to the ``<signal>`` signal with * **signals.E001**: ``<handler>`` was connected to the ``<signal>`` signal with
a lazy reference to the sender ``<app label>.<model>``, but app ``<app label>`` a lazy reference to the sender ``<app label>.<model>``, but app ``<app label>``
isn't installed or doesn't provide model ``<model>``. isn't installed or doesn't provide model ``<model>``.
Backwards Compatibility Templates
~~~~~~~~~~~~~~~~~~~~~~~ ---------
The following checks are performed to warn the user of any potential problems The following checks verify that your :setting:`TEMPLATES` setting is correctly
that might occur as a result of a version upgrade. configured:
* **1_6.W001**: Some project unit tests may not execute as expected. *This * **templates.E001**: You have ``'APP_DIRS': True`` in your
check was removed in Django 1.8 due to false positives*. :setting:`TEMPLATES` but also specify ``'loaders'`` in ``OPTIONS``. Either
* **1_6.W002**: ``BooleanField`` does not have a default value. *This remove ``APP_DIRS`` or remove the ``'loaders'`` option.
check was removed in Django 1.8 due to false positives*. * **templates.E002**: ``string_if_invalid`` in :setting:`TEMPLATES`
* **1_7.W001**: Django 1.7 changed the global defaults for the :setting:`OPTIONS <TEMPLATES-OPTIONS>` must be a string but got: ``{value}``
``MIDDLEWARE_CLASSES.`` (``{type}``).
``django.contrib.sessions.middleware.SessionMiddleware``,
``django.contrib.auth.middleware.AuthenticationMiddleware``, and
``django.contrib.messages.middleware.MessageMiddleware`` were removed from
the defaults. If your project needs these middleware then you should
configure this setting. *This check was removed in Django 1.9*.
* **1_8.W001**: The standalone ``TEMPLATE_*`` settings were deprecated in
Django 1.8 and the :setting:`TEMPLATES` dictionary takes precedence. You must
put the values of the following settings into your defaults ``TEMPLATES``
dict: ``TEMPLATE_DIRS``, ``TEMPLATE_CONTEXT_PROCESSORS``, ``TEMPLATE_DEBUG``,
``TEMPLATE_LOADERS``, ``TEMPLATE_STRING_IF_INVALID``.
* **1_10.W001**: The ``MIDDLEWARE_CLASSES`` setting is deprecated in Django
1.10 and the :setting:`MIDDLEWARE` setting takes precedence. Since you've
set ``MIDDLEWARE``, the value of ``MIDDLEWARE_CLASSES`` is ignored.
Admin URLs
----- ----
The following checks are performed on your URL configuration:
* **urls.W001**: Your URL pattern ``<pattern>`` uses
:func:`~django.conf.urls.include` with a ``regex`` ending with a
``$``. Remove the dollar from the ``regex`` to avoid problems
including URLs.
* **urls.W002**: Your URL pattern ``<pattern>`` has a ``regex``
beginning with a ``/``. Remove this slash as it is unnecessary.
If this pattern is targeted in an :func:`~django.conf.urls.include`, ensure
the :func:`~django.conf.urls.include` pattern has a trailing ``/``.
* **urls.W003**: Your URL pattern ``<pattern>`` has a ``name``
including a ``:``. Remove the colon, to avoid ambiguous namespace
references.
* **urls.E004**: Your URL pattern ``<pattern>`` is invalid. Ensure that
``urlpatterns`` is a list of :func:`~django.conf.urls.url()` instances.
* **urls.W005**: URL namespace ``<namespace>`` isn't unique. You may not be
able to reverse all URLs in this namespace.
* **urls.E006**: The :setting:`MEDIA_URL`/ :setting:`STATIC_URL` setting must
end with a slash.
``contrib`` app checks
======================
``admin``
---------
Admin checks are all performed as part of the ``admin`` tag. Admin checks are all performed as part of the ``admin`` tag.
@ -457,8 +620,8 @@ The following checks are performed on the default
* **admin.E402**: :mod:`django.contrib.auth.context_processors.auth` * **admin.E402**: :mod:`django.contrib.auth.context_processors.auth`
must be in :setting:`TEMPLATES` in order to use the admin application. must be in :setting:`TEMPLATES` in order to use the admin application.
Auth ``auth``
---- --------
* **auth.E001**: ``REQUIRED_FIELDS`` must be a list or tuple. * **auth.E001**: ``REQUIRED_FIELDS`` must be a list or tuple.
* **auth.E002**: The field named as the ``USERNAME_FIELD`` for a custom user * **auth.E002**: The field named as the ``USERNAME_FIELD`` for a custom user
@ -484,9 +647,8 @@ Auth
property rather than a method. Ignoring this is a security issue as anonymous property rather than a method. Ignoring this is a security issue as anonymous
users will be treated as authenticated! users will be treated as authenticated!
``contenttypes``
Content Types ----------------
-------------
The following checks are performed when a model contains a The following checks are performed when a model contains a
:class:`~django.contrib.contenttypes.fields.GenericForeignKey` or :class:`~django.contrib.contenttypes.fields.GenericForeignKey` or
@ -500,117 +662,8 @@ The following checks are performed when a model contains a
* **contenttypes.E004**: ``<field>`` is not a ``ForeignKey`` to * **contenttypes.E004**: ``<field>`` is not a ``ForeignKey`` to
``contenttypes.ContentType``. ``contenttypes.ContentType``.
Security ``sites``
-------- ---------
The security checks do not make your site secure. They do not audit code, do
intrusion detection, or do anything particularly complex. Rather, they help
perform an automated, low-hanging-fruit checklist. They help you remember the
simple things that improve your site's security.
Some of these checks may not be appropriate for your particular deployment
configuration. For instance, if you do your HTTP to HTTPS redirection in a load
balancer, it'd be irritating to be constantly warned about not having enabled
:setting:`SECURE_SSL_REDIRECT`. Use :setting:`SILENCED_SYSTEM_CHECKS` to
silence unneeded checks.
The following checks are run if you use the :option:`check --deploy` option:
* **security.W001**: You do not have
:class:`django.middleware.security.SecurityMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES` so the :setting:`SECURE_HSTS_SECONDS`,
:setting:`SECURE_CONTENT_TYPE_NOSNIFF`, :setting:`SECURE_BROWSER_XSS_FILTER`,
and :setting:`SECURE_SSL_REDIRECT` settings will have no effect.
* **security.W002**: You do not have
:class:`django.middleware.clickjacking.XFrameOptionsMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, so your pages will not be served with an
``'x-frame-options'`` header. Unless there is a good reason for your
site to be served in a frame, you should consider enabling this
header to help prevent clickjacking attacks.
* **security.W003**: You don't appear to be using Django's built-in cross-site
request forgery protection via the middleware
(:class:`django.middleware.csrf.CsrfViewMiddleware` is not in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`). Enabling the middleware is the safest
approach to ensure you don't leave any holes.
* **security.W004**: You have not set a value for the
:setting:`SECURE_HSTS_SECONDS` setting. If your entire site is served only
over SSL, you may want to consider setting a value and enabling :ref:`HTTP
Strict Transport Security <http-strict-transport-security>`. Be sure to read
the documentation first; enabling HSTS carelessly can cause serious,
irreversible problems.
* **security.W005**: You have not set the
:setting:`SECURE_HSTS_INCLUDE_SUBDOMAINS` setting to ``True``. Without this,
your site is potentially vulnerable to attack via an insecure connection to a
subdomain. Only set this to ``True`` if you are certain that all subdomains of
your domain should be served exclusively via SSL.
* **security.W006**: Your :setting:`SECURE_CONTENT_TYPE_NOSNIFF` setting is not
set to ``True``, so your pages will not be served with an
``'x-content-type-options: nosniff'`` header. You should consider enabling
this header to prevent the browser from identifying content types incorrectly.
* **security.W007**: Your :setting:`SECURE_BROWSER_XSS_FILTER` setting is not
set to ``True``, so your pages will not be served with an
``'x-xss-protection: 1; mode=block'`` header. You should consider enabling
this header to activate the browser's XSS filtering and help prevent XSS
attacks.
* **security.W008**: Your :setting:`SECURE_SSL_REDIRECT` setting is not set to
``True``. Unless your site should be available over both SSL and non-SSL
connections, you may want to either set this setting to ``True`` or configure
a load balancer or reverse-proxy server to redirect all connections to HTTPS.
* **security.W009**: Your :setting:`SECRET_KEY` has less than 50 characters or
less than 5 unique characters. Please generate a long and random
``SECRET_KEY``, otherwise many of Django's security-critical features will be
vulnerable to attack.
* **security.W010**: You have :mod:`django.contrib.sessions` in your
:setting:`INSTALLED_APPS` but you have not set
:setting:`SESSION_COOKIE_SECURE` to ``True``. Using a secure-only session
cookie makes it more difficult for network traffic sniffers to hijack user
sessions.
* **security.W011**: You have
:class:`django.contrib.sessions.middleware.SessionMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but you have not set
:setting:`SESSION_COOKIE_SECURE` to ``True``. Using a secure-only session
cookie makes it more difficult for network traffic sniffers to hijack user
sessions.
* **security.W012**: :setting:`SESSION_COOKIE_SECURE` is not set to ``True``.
Using a secure-only session cookie makes it more difficult for network traffic
sniffers to hijack user sessions.
* **security.W013**: You have :mod:`django.contrib.sessions` in your
:setting:`INSTALLED_APPS`, but you have not set
:setting:`SESSION_COOKIE_HTTPONLY` to ``True``. Using an ``HttpOnly`` session
cookie makes it more difficult for cross-site scripting attacks to hijack user
sessions.
* **security.W014**: You have
:class:`django.contrib.sessions.middleware.SessionMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but you have not set
:setting:`SESSION_COOKIE_HTTPONLY` to ``True``. Using an ``HttpOnly`` session
cookie makes it more difficult for cross-site scripting attacks to hijack user
sessions.
* **security.W015**: :setting:`SESSION_COOKIE_HTTPONLY` is not set to ``True``.
Using an ``HttpOnly`` session cookie makes it more difficult for cross-site
scripting attacks to hijack user sessions.
* **security.W016**: :setting:`CSRF_COOKIE_SECURE` is not set to ``True``.
Using a secure-only CSRF cookie makes it more difficult for network traffic
sniffers to steal the CSRF token.
* **security.W017**: :setting:`CSRF_COOKIE_HTTPONLY` is not set to ``True``.
Using an ``HttpOnly`` CSRF cookie makes it more difficult for cross-site
scripting attacks to steal the CSRF token. *This check is removed in Django
1.11 as the* :setting:`CSRF_COOKIE_HTTPONLY` *setting offers no pratical
benefit.*
* **security.W018**: You should not have :setting:`DEBUG` set to ``True`` in
deployment.
* **security.W019**: You have
:class:`django.middleware.clickjacking.XFrameOptionsMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but :setting:`X_FRAME_OPTIONS` is not set to
``'DENY'``. The default is ``'SAMEORIGIN'``, but unless there is a good reason
for your site to serve other parts of itself in a frame, you should change
it to ``'DENY'``.
* **security.W020**: :setting:`ALLOWED_HOSTS` must not be empty in deployment.
* **security.W021**: You have not set the
:setting:`SECURE_HSTS_PRELOAD` setting to ``True``. Without this, your site
cannot be submitted to the browser preload list.
Sites
-----
The following checks are performed on any model using a The following checks are performed on any model using a
:class:`~django.contrib.sites.managers.CurrentSiteManager`: :class:`~django.contrib.sites.managers.CurrentSiteManager`:
@ -619,61 +672,3 @@ The following checks are performed on any model using a
``<field name>``. ``<field name>``.
* **sites.E002**: ``CurrentSiteManager`` cannot use ``<field>`` as it is not a * **sites.E002**: ``CurrentSiteManager`` cannot use ``<field>`` as it is not a
foreign key or a many-to-many field. foreign key or a many-to-many field.
Database
--------
MySQL
~~~~~
If you're using MySQL, the following checks will be performed:
* **mysql.E001**: MySQL does not allow unique ``CharField``\s to have a
``max_length`` > 255.
* **mysql.W002**: MySQL Strict Mode is not set for database connection
'<alias>'. See also :ref:`mysql-sql-mode`.
Templates
---------
The following checks verify that your :setting:`TEMPLATES` setting is correctly
configured:
* **templates.E001**: You have ``'APP_DIRS': True`` in your
:setting:`TEMPLATES` but also specify ``'loaders'`` in ``OPTIONS``. Either
remove ``APP_DIRS`` or remove the ``'loaders'`` option.
* **templates.E002**: ``string_if_invalid`` in :setting:`TEMPLATES`
:setting:`OPTIONS <TEMPLATES-OPTIONS>` must be a string but got: ``{value}``
(``{type}``).
Caches
------
The following checks verify that your :setting:`CACHES` setting is correctly
configured:
* **caches.E001**: You must define a ``'default'`` cache in your
:setting:`CACHES` setting.
URLs
----
The following checks are performed on your URL configuration:
* **urls.W001**: Your URL pattern ``<pattern>`` uses
:func:`~django.conf.urls.include` with a ``regex`` ending with a
``$``. Remove the dollar from the ``regex`` to avoid problems
including URLs.
* **urls.W002**: Your URL pattern ``<pattern>`` has a ``regex``
beginning with a ``/``. Remove this slash as it is unnecessary.
If this pattern is targeted in an :func:`~django.conf.urls.include`, ensure
the :func:`~django.conf.urls.include` pattern has a trailing ``/``.
* **urls.W003**: Your URL pattern ``<pattern>`` has a ``name``
including a ``:``. Remove the colon, to avoid ambiguous namespace
references.
* **urls.E004**: Your URL pattern ``<pattern>`` is invalid. Ensure that
``urlpatterns`` is a list of :func:`~django.conf.urls.url()` instances.
* **urls.W005**: URL namespace ``<namespace>`` isn't unique. You may not be
able to reverse all URLs in this namespace.
* **urls.E006**: The :setting:`MEDIA_URL`/ :setting:`STATIC_URL` setting must
end with a slash.