This might be a stupid question and have an obvious answer, but I was testing my 404 and 500 error handlers meaning that I had to switch debug to False. I went to Django admin page and noticed that static files are not being served.
I understand that they should be routed through Apache as serving static files through Django is insecure. However, I don't quite understand why is it a security risk to serve static files through Django directly?
What Are Static Files? Static files are files that don't change when your application is running. These files do a lot to improve your application, but they aren't dynamically generated by your Python web server like a usual HTML response.
Using the collectstatic command, Django looks for all static files in your apps and collects them wherever you told it to, i.e. the STATIC_ROOT . In our case, we are telling Django that when we run python manage.py collectstatic , gather all static files into a folder called staticfiles in our project root directory.
Here is what the Django 1.8 documentation says on the subject:
--insecure
Use the
--insecure
option to force serving of static files with the staticfiles app even if theDEBUG
setting isFalse
. By using this you acknowledge the fact that it’s grossly inefficient and probably insecure. This is only intended for local development, should never be used in production and is only available if thestaticfiles
app is in your project’sINSTALLED_APPS
setting.
As you can see, they say "grossly inefficient" and "probably insecure". They didn't say "definitely insecure" or "insecure". I think that what they are hinting at is that they haven't done a thorough security analysis of the staticfiles
app and its interactions with the rest of Django.
For me, the "grossly inefficient" part should be sufficient to deter you from serving static content. It is easy to do it better ... starting with the collectstatic
command.
Some more searching lead me to this Google Groups posting, in response to someone asking about why --insecure
is insecure.
From: Malcolm Tredinnick
Nothing can be considered secure unless it is designed and audited for security. We have done neither with the static file server. It may not have existing security holes, but it should not be considered secure because that's not a design goal.
For example, a secure file server would need to check for resource allocation problems so that serving a very large file didn't constitute a denial-of-service attack. That requires a lot of extra code and pipeline management which isn't worth putting into something that's just for development purposes.
... which supports my interpretation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With