That attack doesn't work with the recommended production setup because
Django doesn't serve uploaded files in that setup.
That being said, some users might be doing that anyway since setting
up production-worthy upload hosting is such a pain, and even if they
don't, they might have other views tha
getting started.
>>>
>>> We could go a small step forward and use `check --deploy` to check for
>>> the substring `insecure` (even though I believe the KEY is technically
>>> bytes?).
>>>
>>> Just throwing something out there.
>>>
&
(Disclosure: I'm on Google's security team, and my views on this topic are
informed by what kinds of things we tend to look for in Web frameworks, but
here I don't speak for them, only for myself.)
Beyond those already mentioned, here are some potential security
improvements I'd like to see in Dja
Is the requirement here to avoid introduce additional barriers to getting
up and running in local development, or to deploying a site so that it's
accessible from the public internet?
Both of these are important goals, but trading off security against the
latter worries me. I don't think we're
