[jacobian]

It's a tough line to draw. Requiring users to whitelist every domain that might be used to access the app is a PITA, and makes the lives of new developers more annoying. (It also makes multi-tennancy by domain name, e.g. customer.example.com, a bit more difficult.)

On the other hand, you're completely right that the "you gotta get your upstream server configured correctly" advice is handwavy at best.

Seems like this is always the case, this tension between security and usability...

If you've got bright ideas, I'd love to hear 'em. Maybe join us on django-dev (http://groups.google.com/group/django-developers) if you do?

[gojomo]

Thanks for the invite.

However, my idea is just what's already outlined above: avoid using 'Host', except (perhaps) as a key.

Declaring one or more approved hostnames for accessing an install isn't an onerous requirement (especially if you're assuming that when they're not doing it in Django, they must do it elsewhere to be safe).

Maybe some people (such as in multi-tenancy situations or to make dev/staging/production transitions easier) will choose to use 'Host' directly anyway, or some sort of wildcard for acceptable hostnames. That's fine, but then they'll be accepting the risk by conscious action, deviating from the safer default. That seems better than facing the risk by the inaction of overlooking this more-subtle webserver-configuration issue.

[jacobian]

> However, my idea is just what's already outlined above: avoid using 'Host', except (perhaps) as a key.

Yes, this is a good idea in theory (it's an offshoot of the idea of avoiding using any data that's provided by the browser.) But in practice, it breaks down any time you need to generate a full URL into the site, i.e.:

* Callback URLs for schemes like OAuth, webhooks, IPN, etc. * Transaction emails with links back to the site ("this week on example.com", "joe just mentioned you..." password resets, etc.) * Links in Atom, RSS feeds, etc.

In each case, Django could require that hosts be hardcoded (perhaps in settings) instead of consulting requests, but that would make each of those things harder to use.

... I'm not really trying to have an argument here; I see your point completely and I think I probably agree, personally. But I am trying to point out that security and usability are often at odds, and that there isn't as much a "right answer" as there is a calibration between those two needs. Drawing the line in the right place is hard.