Django docs suggests SecurityMiddleware is placed near the top of your
MIDDLEWARE settings for good reason: it performs a suite of security checks and enhancements that would otherwise leave your website to the mercy of some simple hacks.
Ready for a Django security challenge? Play our Django security challenge.
SecurityMiddleware sets the
X-Content-Type-Options header to
This header indicate to the browser that the MIME types advertised in the Content-Type headers should not be changed (by "sniffing" the content). The sniffing feature is the browser being helpful when a developer or server misconfiguration misidentified the
# settings.py MIDDLEWARE = [ # "django.middleware.security.SecurityMiddleware", "django.middleware.common.CommonMiddleware", "django.contrib.sessions.middleware.SessionMiddleware", ... ] SECURE_CONTENT_TYPE_NOSNIFF = False # pre-Django 3.0 it was False by default. Post 3.0 it's True # views.py class HomePage(View): def get(self, *args, **kwargs): # simulate a misconfgured server that returns a response that has no content type response = HttpResponse("<script>alert('hello world')</script>") del response['Content-Type'] return response
The outcome when navigating to
HomePage shows the "hack" worked:
This simple proof of concept simulated the following more complex situation:
- The file was served by your website but does not set MIME type in the Content-Type header
- The browser inferred the MIME type based on the content
This would be avoided if we the
SecurityMiddleware is present and the
nosniff feature is active:
# settings.py MIDDLEWARE = [ "django.middleware.security.SecurityMiddleware", "django.middleware.common.CommonMiddleware", "django.contrib.sessions.middleware.SessionMiddleware", ... ] SECURE_CONTENT_TYPE_NOSNIFF = True
Then the browser does not fall for the trick:
SecurityMiddleware sets the
X-XSS-Protection header to
1; mode=block when
True to enable the browser's built-in XSS protection.
This XSS protection has been mostly superseded by CSP. Older browsers still support this feature, but many browsers have removed this feature. Users with older browsers are still important to cater for because security of your website cannot assume everyone is running the latest version of Chrome.
SECURE_BROWSER_XSS_FILTER then the website will not receive the benefit of being protected against the many possible XSS attacks.
SecurityMiddleware sets the referer policy header based on
SECURE_REFERRER_POLICY, which impacts user privacy and is an attack vector for bad actors that aim to dupe users into thinking they are still on your website.
The referer header can be abused by the target website: maybe secrets in the your website URL is leaked. More convolutedly, maybe a bad actor can add a link to their website. The target can then read the referer header and style their website to look like your website. A user not paying attention may think they're still on your website because:
- your website linked to it
- it looks like your website
So the user may then input credentials and personal details in the bad actor's website.
This can be prevented by not exposing the referer header by settings
SECURE_REFERRER_POLICY, which is then handled by the
SecurityMiddleware can redirect HTTP connections to HTTPS if
SECURE_SSL_REDIRECT is set to
If you do not redirect HTTP to HTTPS then passwords and personal information will be transported over plaintext, and a Man In The Middle could read them.
Or try out Django refactor challenges.