djangosecuritydjango-staticfilesstatic-files

Why is serving static files insecure

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?

Solution

  • 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 the DEBUG setting is False. 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 the staticfiles app is in your project’s INSTALLED_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.