|
@@ -168,7 +168,7 @@ certain cases. While these values are sanitized to prevent Cross Site Scripting
|
|
|
attacks, a fake ``Host`` value can be used for Cross-Site Request Forgery,
|
|
|
cache poisoning attacks, and poisoning links in emails.
|
|
|
|
|
|
-Because even seemingly-secure webserver configurations are susceptible to fake
|
|
|
+Because even seemingly-secure web server configurations are susceptible to fake
|
|
|
``Host`` headers, Django validates ``Host`` headers against the
|
|
|
:setting:`ALLOWED_HOSTS` setting in the
|
|
|
:meth:`django.http.HttpRequest.get_host()` method.
|
|
@@ -181,15 +181,15 @@ For more details see the full :setting:`ALLOWED_HOSTS` documentation.
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
- Previous versions of this document recommended configuring your webserver to
|
|
|
+ Previous versions of this document recommended configuring your web server to
|
|
|
ensure it validates incoming HTTP ``Host`` headers. While this is still
|
|
|
- recommended, in many common webservers a configuration that seems to
|
|
|
+ recommended, in many common web servers a configuration that seems to
|
|
|
validate the ``Host`` header may not in fact do so. For instance, even if
|
|
|
Apache is configured such that your Django site is served from a non-default
|
|
|
virtual host with the ``ServerName`` set, it is still possible for an HTTP
|
|
|
request to match this virtual host and supply a fake ``Host`` header. Thus,
|
|
|
Django now requires that you set :setting:`ALLOWED_HOSTS` explicitly rather
|
|
|
- than relying on webserver configuration.
|
|
|
+ than relying on web server configuration.
|
|
|
|
|
|
Additionally, as of 1.3.1, Django requires you to explicitly enable support for
|
|
|
the ``X-Forwarded-Host`` header (via the :setting:`USE_X_FORWARDED_HOST`
|