Security headers are statements we add to HTTP responses that instruct the web browser on how to handle the content it obtains without giving unauthorized access to its user’s information or computing resources.
It is possible to tamper with the network and the documents it transports, in many ways. Consequently a browser may compromise its host computer as it processes content manipulated by a third-party with malicious intent.
Modern browsers implement security measures to avert or mitigate these dangers. Security headers play a role in these mechanisms.
ssl.confValue: "DENY"
This header tells the browser it should not render any of our content on a web page that embeds it.
Value: "nosniff"
The browser should not decide that one of our files is executable if we have not said it is
Value: "1; mode-block"
We are telling the browser to not render our content if it detects a reflected cross site scripting attack.
The basic form of reflected XSS begins with a URL, crafted by an attacker, in which data that should be user input is in reality executable content. If the server that handles the URL does not sanitize the user input in it, the visitor browser will execute the malicious payload as it receives the server’s reply.
XSS on OWASP
Cross site scripting article on Wikipedia
Handling of X-XSS-Protection has been deprecated in latest browsers. But we still deploy the header for the older browsers that will visit our site.
OWASP XSS Prevention Cheat Sheet - header deprecated
Value: "same-origin"
The browser should not pass information about any site that links to us in the “Referer” header.
Referrer-Policy on MDN
“Referer” header on MDN
With these headers we are declaring we do not need to access any special feature the browser may offer, such as camera, microphone, speaker and so on.
This header identifies what content and which web locations the browser should trust. We create the header on Django, using the django-csp package.
The file django/base_app/settings.py contains the directives in the CSP header.
CSP quick reference
CSP on OWASP
style and script elementsCSP lets us define trusted style and script elements in the HTML. These elements occur in the templates we have in Django. They are now decorated with nonce attributes.
For every page that Django generates, django-csp creates a new nonce that it inserts in the HTTP response. The nonce is then available to be used in the templates.
<script nonce=""></script>
<style nonce=""></style>
The browser receives the nonce in the CSP header. It then knows it can trust the nonce’d elements by checking their values are equal to the nonce in the header. All script and style elements without a nonce are discarded.