[Django] #35458: Docs: clarify need for ALLOWED_HOSTS

[Django]

#35458: Docs: clarify need for ALLOWED_HOSTS
----------------------------------------------+------------------------
Reporter: Klaas van Schelven | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 5.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
----------------------------------------------+------------------------
I understand why [https://security.stackexchange.com/questions/45687/what-
does-djangos-allowed-hosts-variable-actually-do validation of the host
header is important] but I do not understand why this would be the
responsibility of Django.

The [https://docs.djangoproject.com/en/5.0/ref/settings/#allowed-hosts
docs for the settings] mysteriously mention

> which are possible even under many seemingly-safe web server
configurations.

and the [https://docs.djangoproject.com/en/5.0/topics/security/#host-
headers-virtual-hosting docs for the host header validation] mention
something similar:

> Because even seemingly-secure web server configurations are susceptible
to fake Host headers

and

> 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 web servers a configuration that seems
to validate the Host header may not in fact do so. For instance, even if
Apache [..]

However, these notes were added in 2013, when Apache still reigned supreme
(moreover: a very different version, possibly with less sane defaults, of
Apache). These days there are many more ways Django is deployed, not least
of which cloud-based ones in which the passing of sane (actually checked)
host headers is left up to some web-facing proxy / webserver in front of
Django.

In 2024, is there still any reason to fear these "many" (undocumented)
"seemingly-safe server configurations" or can I just use a sane proxy
server and let that do the validation instead? Setting `ALLOWED_HOSTS` to
`["*"]` removes one more thing to think about while deploying.

In the context of a bug report (and not just a question): the
documentation should clarify what the actual wrong configurations would
be, it should be mentioned as "defense in depth" rather than a first line
of defense or the whole idea of ALLOWED_HOSTS checking should be removed.

[https://stackoverflow.com/q/78476951/339144 Previously asked on
StackOverflow in slightly different words]
--
Ticket URL: <https://code.djangoproject.com/ticket/35458>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35458: Docs: clarify need for ALLOWED_HOSTS

------------------------------------+--------------------------------------

Reporter: Klaas van Schelven | Owner: nobody

Type: Uncategorized | Status: closed
Component: Documentation | Version: 5.0
Severity: Normal | Resolution: needsinfo

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

------------------------------------+--------------------------------------
Changes (by Sarah Boyce):

* component: Uncategorized => Documentation
* resolution: => needsinfo
* status: new => closed

Comment:

I believe the [https://docs.djangoproject.com/en/5.0/releases/1.4.4/#host-
header-poisoning Django 1.4.4 release notes] gives more context.

I think you're suggesting that Django should recommend or imply having
`ALLOWED_HOSTS` as `["*"]` is safe.
You should discuss this on the
[https://forum.djangoproject.com/c/internals/5 Django forum] and state why
this should be updated/allowed. As this relates to security, we need very
strong consensus and evidence that this is safe before we can make an
update. The security team may also want to review such an update. During
this discussion you might conclude to add some doc clarifications.

I am closing this request for now but if after a discussion you have a
concrete proposal, please reopen the ticket for consideration.
--
Ticket URL: <https://code.djangoproject.com/ticket/35458#comment:1>

[Django]

#35458: Docs: clarify need for ALLOWED_HOSTS
------------------------------------+--------------------------------------
Reporter: Klaas van Schelven | Owner: nobody
Type: Uncategorized | Status: closed
Component: Documentation | Version: 5.0
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------------+--------------------------------------

Comment (by Klaas van Schelven):

Those notes give slightly more context, but not too much more. i.e. "it
has been reported to us that even with the recommended web server
configurations there are still techniques available for tricking many
common web servers into supplying the application with an incorrect and
possibly malicious Host header." still leaves me to wonder what these
techniques would be and how one could defend against them at the level of
the webserver (Apache, Nginx) rather than Django.

> I think you're suggesting that Django should recommend or imply having
`ALLOWED_HOSTS` as `["*"]` is safe.

This was indeed one of the options in my original post. However, having
since tried my hand at properly configuring the front-facing part, I have
come to the conclusion that defense in depth is indeed a good
recommendation. Still, I think the wording of the docs could be more
clear, but I have to admit I don't have a good alternative myself.

Closing this issue for now is good for me.
--
Ticket URL: <https://code.djangoproject.com/ticket/35458#comment:2>

[Django]

#35458: Docs: clarify need for ALLOWED_HOSTS
------------------------------------+--------------------------------------
Reporter: Klaas van Schelven | Owner: nobody
Type: Uncategorized | Status: closed
Component: Documentation | Version: 5.0
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------------+--------------------------------------
Comment (by Klaas van Schelven):

In addition: setting up a 'catch all' for SSL may be "somewhat hard", as
e.g. documented [https://serverfault.com/questions/578648/properly-
setting-up-a-default-nginx-server-for-https/1044022 here for nginx]. This
in turn may mean a site gets traffic that's not meant for it.
--
Ticket URL: <https://code.djangoproject.com/ticket/35458#comment:3>