Cheat sheet: Django security tips
Lucky you, you user of the web framework for
perfectionists with deadlines (AKA Django). The
Django team has put a lot of thought into their
security practice (find security features in their
documentation and their security policy is interest-
ing too). We have summarized some of the best
tips to keep your Django project secure.
Django Security tips
What version of Django are you using? Django currently has
three major versions in use (though long term support for 1.11 is
ending in April 2020). The version of Django you use has a
number of implications on your project. For instance, Django
1.11 is the last version to use Python 2 (which was sunsetted at
the beginning of 2020).
Additionally, the choice of version determines what known
vulnerabilities are present and potentially exploitable in your
application. Learn more about known Django vulnerabilities
from our vulnerability database or scan your project with Snyk,
and we will let you know if you are using a vulnerable version.
Finally, it is important that you have a plan in place to keep your
Django version up to date. Generally it is a good idea to settle
on a long term supported version and have a plan for moving to
the next one up before support ends for your current version.
That way you benefit from maintainer support, but you don’t
have to be changing your version constantly.
Additionally, be sure that you are referencing documentation
from the correct Django version. You would not want to believe
a security policy is in place because you read about it in the
documentation, only to discover that there was a mismatch
between the version you are using and the documentation you
are reading.
Throttle user authentications
Django provides a lot of security features baked in, but the
authentication system does not inherently protect against brute
force attacks. A malicious actor could hit your system with
numerous login attempts, and potentially get in.
If this kind of attack is of concern for your project, use a project
like Django Defender to lock out users after too many login
attempts.
Protect your source code
Protecting your source code may seem to be an obvious step,
but it is a multi-faceted step and is, therefore, worth exploring.
One way to protect your source code is to make sure that it is
not included in your web server’s root directory. If it is, there is a
possibility that it is served or that, part of it, is executed in a way
that you had not planned.
And although it goes without saying, if your project is sensitive,
be sure to use a private repository on GitHub, Bitbucket, or
Gitlab. Also, make sure to never check your secrets into your
version control system, regardless of whether you intend to use
a private repo. It is possible that a private repository does not
always stay private and someone with access to a private repo
cannot always be trusted.
Use raw queries and custom SQL with caution
While it is tempting to write raw sql queries and custom SQL,
doing so may open the door for an attack. Django’s object-rela-
tional-mapping (ORM) framework is designed to make querying
your database easy. Querysets are constructed using query
paramatization. The queries parameters have been abstracted
away from the queries sql code. A user attempting to perform a
sql injection (execute arbitrary sql on a database) is going to
find it much harder if you always use the ORM.
Django does allow the use of raw queries, but their use is
not recommended. If you do use them, take extra care to
properly escape any parameters. If you find the Django
ORM to be insufficient for your needs, it is possible to use
a different ORM within Django. SQLAlchemy is an
example of an ORM that can be used with Django. If there
is an ORM that better suits your project, making use of it is
preferable to writing large amounts of raw sql.
Use https
Regardless of your framework of choice, it is always
preferable to deploy behind HTTPS. Doing so prevents
malicious users from intercepting information sent
between the client and the server. For https to work
correctly, it is important to be sure that you have properly
determined your settings.
The following settings are important to your use of https.
Be sure you understand them and enable them properly.
The documentation does a good job of explaining the
settings, the secure defaults, and why you might need to
change them in a given circumstance.
SECURE_PROXY_SSL_HEADER
SECURE_SSL_REDIRECT
SESSION_COOKIE_SECURE
CSRF_COOKIE_SECURE
SECURE_HSTS_SECONDS
SECURE_HSTS_INCLUDE_SUBDOMAINS
SECURE_HSTS_PRELOAD
www.snyk.io
Cheat sheet: Django security tips
Watch your headers
First, we want to specifically consider the referer request header.
This header contains the address of the previous web page from
which you arrived at the current page. This information is useful
for analytics, among other things. Sometimes though, It causes
problems because, generally, people do not like to be followed
around the web. Due to privacy concerns, it is possible to
disable this functionality. Whether a referer request header is
passed along, can be determined by the referer-policy header.
Under certain conditions, partial information is passed along —
in others, all of the information is included, and sometimes no
referer request header information is forwarded.
When the site is served via https, the referer request header is
utilized by Django to help prevent cross site request forgery
(CRSF) attacks. If you are too strict with your referer-policy
header, you disable the functionality of Django’s CRSF protec-
tion. In the end, you need to weigh the privacy benefits of using
a strict referer-policy header with the benefits of the CRSF
protection. It is possible to “split the difference” by only
enabling same-origin referrers in your referer-policy header.
Be careful with your cookies
Some cookies are more secure than others — the default cookie
behavior is to connect over http. However, since we already
established that you need to use https, you want to make sure
your cookies are only being sent over https as well. To prevent
leaking cookies, be sure to set your SESSION_COOKIE_SECURE
and CSRF_COOKIE_SECURE settings to True. This instructs the
browser to only send these cookies over HTTPS connections.
There are some interesting side effects to setting these
parameters to true, but they should be mitigated by redirecting
http traffic to https.
Carefully handle user uploads When you include Django (or any open source library for that
matter), typically, you are also including every library that your
If your web application allows users to upload files, you are library of choice utilizes. Open source is built on open source
opening yourself to an attack vector and the upload logic should which is built on more open source.
therefore be handled carefully. First, it is important to validate
all uploaded files to be sure they are what you expect (for Indirect dependencies are as likely to introduce risk as direct
instance, an image file and not a PHP script!). You don’t want it dependencies, but these risks are less likely to be recognized. A
to be possible for a user to run code. tool like Snyk helps you understand your entire dependency
tree, and now that Snyk offers fix pull requests for Python, fixing
problems (even in indirect dependencies) is easier than ever.
There are a number of things to help validate uploaded files or
handle them more carefully. They include the following: Don’t let the perfect get in the way of the good
• Create a whitelist of acceptable file types Every security step you take is a step in the right direction.
Limit file size allowed for uploads to prevent denial of Django may be for perfectionists with deadlines, but code
service problems doesn’t have to be perfect to reap security benefits. Implement-
• Disable handlers that would execute static files as code ing the concepts discussed above, to the best of your ability, can
(for example, disable Apache’s mod_php) dramatically improve the security of your code and result in a
healthier, more resilient project. Happy coding, pythonistas!
• Make cross site scripting protections work for you. If
you serve user content from a distinct top level
domain, the protections against cross site scripting will
kick in to protect you. This can be a domain that you
manage, although it is probably easier to serve the files
from a cloud service or content delivery network
provider.
Understand all of your dependencies
If you have selected a Django version with little to no known
security risks, you probably think that there are no more security
issues to consider. However, it is important to understand the
open source libraries that Django is importing and whether
there are vulnerabilities in those libraries.
www.snyk.io
Cheat sheet: Django security tips

1. Know your version and use a secure one 7. Be careful with your cookies

What version of Django are you using? The choice of version determines what known
vulnerabilities are present, and potentially exploitable, in your application. Learn more about
known Django vulnerabilities from our vulnerability database or you scan your project with
Snyk.
2. Throttle user authentications
Django provides a lot of security features baked in, but the authentication system does not
inherently protect against brute force attacks. It is important for you to write your own code
to prevent this, or use one of many open source solutions (like Django Defender).
3. Protect your source code
Some cookies are more secure than others — the default cookie behavior is to connect
over http. However, since we already established that you need to use https, you want to
make sure your cookies are only being sent over https as well. To prevent leaking cookies,
be sure to set your SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE settings to
True.
8. Carefully handle user uploads
If your web application allows users to upload files, you are opening yourself to an attack
vector and the upload logic should therefore be handled carefully. It is important to
validate all uploaded files to be sure they are what you expect (for instance, an image file
and not a PHP script!).

Make sure your source code is not included in your web server’s root directory. Use a private
repository if your project is sensitive. Never check your secrets into version control, even if
you are using a private repository.
4. Use raw queries and custom SQL with caution
While it may be tempting to write raw sql queries and custom SQL, doing so may open the
door for an attack. A user attempting to perform an sql injection (execute arbitrary sql on a
database) is going to find it much harder, if you always use the ORM.
5. Use HTTPs
9. Understand all of your dependencies
Indirect dependencies are as likely to introduce risk as direct dependencies, but these risks
are less likely to be recognized. A tool like Snyk helps you understand your entire
dependency tree, and now that Snyk offers fix pull requests for Python, fixing problems
(even in indirect dependencies) is easier than ever.
10. Don’t let the perfect get in the way of the good
Every security step you take is a step in the right direction. Django may be for perfection-
ists with deadlines, but code doesn’t have to be perfect to reap security benefits.

Regardless of your framework of choice, it is always preferable to deploy behind HTTPS.

Doing so prevents malicious users from intercepting information sent between the client
and the server.

6. Watch your headers

When the site is served via https, the referer request header is utilized by Django to help
prevent cross site request forgery (CRSF) attacks. If you are too strict with your referer-policy
header, you disable the functionality of Django’s CRSF protection. In the end you need to
weigh the privacy benefits of using a strict referer-policy header with the benefits of the
CRSF protection. www.snyk.io