Fixed #20330 -- Normalized spelling of "web server".

Thanks Baptiste Mispelon for the report.

docs/topics/security.txt

@@ -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`