|
@@ -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
|
|
|
system checks, see the :doc:`System check topic guide </topics/checks>`.
|
|
|
|
|
|
-API Reference
|
|
|
+API reference
|
|
|
=============
|
|
|
|
|
|
``CheckMessage``
|
|
@@ -66,88 +66,81 @@ class name.
|
|
|
.. class:: Error(msg, hint=None, obj=None, id=None)
|
|
|
.. class:: Critical(msg, hint=None, obj=None, id=None)
|
|
|
|
|
|
-Builtin checks
|
|
|
-==============
|
|
|
-
|
|
|
.. _system-check-builtin-tags:
|
|
|
|
|
|
Builtin 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.
|
|
|
-* ``compatibility``: Flagging potential problems with version upgrades.
|
|
|
-* ``security``: Checks security related configuration.
|
|
|
-* ``templates``: Checks template 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
|
|
|
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
|
|
|
you specify the ``database`` tag when calling the :djadmin:`check` command.
|
|
|
-
|
|
|
-.. versionadded:: 1.10
|
|
|
-
|
|
|
- The ``database`` tag was added.
|
|
|
+* ``models``: Checks of model, field, and manager definitions.
|
|
|
+* ``security``: Checks security related configuration.
|
|
|
+* ``signals``: Checks on signal declarations and handler registrations.
|
|
|
+* ``templates``: Checks template related configuration.
|
|
|
+* ``urls``: Checks URL configuration.
|
|
|
|
|
|
Some checks may be registered with multiple tags.
|
|
|
|
|
|
Core system checks
|
|
|
-------------------
|
|
|
+==================
|
|
|
|
|
|
-Models
|
|
|
-~~~~~~
|
|
|
+Backwards compatibility
|
|
|
+-----------------------
|
|
|
|
|
|
-* **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.
|
|
|
+The following checks are performed to warn the user of any potential problems
|
|
|
+that might occur as a result of a version upgrade.
|
|
|
+
|
|
|
+* **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
|
|
|
+------
|
|
|
|
|
|
-Fields
|
|
|
-~~~~~~
|
|
|
+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.E002**: Field names must not contain ``"__"``.
|
|
@@ -183,7 +176,7 @@ Fields
|
|
|
* **fields.W901**: ``CommaSeparatedIntegerField`` has been deprecated. Support
|
|
|
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``.
|
|
@@ -193,7 +186,7 @@ File Fields
|
|
|
path, not an absolute path.
|
|
|
* **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
|
|
@@ -261,41 +254,211 @@ Related Fields
|
|
|
* **fields.W343**: ``limit_choices_to`` has no effect on ``ManyToManyField``
|
|
|
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.E001**: ``<handler>`` was connected to the ``<signal>`` signal with
|
|
|
a lazy reference to the sender ``<app label>.<model>``, but app ``<app label>``
|
|
|
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
|
|
|
-that might occur as a result of a version upgrade.
|
|
|
+The following checks verify that your :setting:`TEMPLATES` setting is correctly
|
|
|
+configured:
|
|
|
|
|
|
-* **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.
|
|
|
+* **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}``).
|
|
|
+
|
|
|
+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.
|
|
|
|
|
|
-Admin
|
|
|
------
|
|
|
+``contrib`` app checks
|
|
|
+======================
|
|
|
+
|
|
|
+``admin``
|
|
|
+---------
|
|
|
|
|
|
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`
|
|
|
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.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
|
|
|
users will be treated as authenticated!
|
|
|
|
|
|
-
|
|
|
-Content Types
|
|
|
--------------
|
|
|
+``contenttypes``
|
|
|
+----------------
|
|
|
|
|
|
The following checks are performed when a model contains a
|
|
|
: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.ContentType``.
|
|
|
|
|
|
-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.
|
|
|
-
|
|
|
-Sites
|
|
|
------
|
|
|
+``sites``
|
|
|
+---------
|
|
|
|
|
|
The following checks are performed on any model using a
|
|
|
:class:`~django.contrib.sites.managers.CurrentSiteManager`:
|
|
@@ -619,61 +672,3 @@ The following checks are performed on any model using a
|
|
|
``<field name>``.
|
|
|
* **sites.E002**: ``CurrentSiteManager`` cannot use ``<field>`` as it is not a
|
|
|
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.
|