The internet is a wild land. Security must be priority one when deploying a web application on the internet. The Django framework does an amazing job providing reliable and secure APIs. But none of that matters if we don’t use them properly.
Nothing new that we should never deploy a Django application with
One of the features of having
DEBUG=True is dumping lots of metadata from your environment, including the whole
settings.py configurations, when a exception occurs.
Even though you will never be using
DEBUG=True, you need extra care when naming the configurations in the
settings.py module. Make sure all sensitive variables use one of the keywords:
This way, Django will not dump those variables that may contain sensitive information.
Even when you are running your application with
DEBUG=False, if it’s configured to send error reports via email,
there is a chance of the error report being exposed, specially if you are transmitting error reports unencrypted over
PS: I mention this a lot here in the blog, but it’s never enough: Don’t commit sensitive information to public repositories. In other words, don’t add sensitive information directly to the settings.py file, instead use environment variable or use python-decouple. Learn more about how to separate configuration from code reading this article I published a while ago: Package of the Week: Python Decouple.
Speaking of filtering error reports, there are two view decorators that you should put in action:
If your code handle sensitive information in local variables inside a view function, explicitly mark them as sensitive to avoid showing them in error reports:
Or if you want to hide all local variables inside a function:
PS: When using multiple decorators make sure the
@sensitive_variables() decorator is the first one.
Similar to the previous example, but this one handle post parameters, as the name suggests:
In a similiar way, to hide all post parameters:
Read more about filtering sensitive information in the official Django docs.