To take advantage of CSRF protection in your views, follow these steps:

While the above method can be used for AJAX POST requests, it has some inconveniences: you have to remember to pass the CSRF token in as POST data with every POST request. For this reason, there is an alternative method: on each XMLHttpRequest, set a custom X-CSRFToken header to the value of the CSRF token. This is often easier, because many JavaScript frameworks provide hooks that allow headers to be set on every request.

As a first step, you must get the CSRF token itself. The recommended source for the token is the csrftoken cookie, which will be set if you've enabled CSRF protection for your views as outlined above.

The CSRF token cookie is named csrftoken by default, but you can control the cookie name via the CSRF_COOKIE_NAME setting.

Acquiring the token is straightforward:

// using jQuery 
function getCookie(name) { 
    var cookieValue = null; 
    if (document.cookie && document.cookie != '') { 
        var cookies = document.cookie.split(';'); 
        for (var i = 0; i < cookies.length; i++) { 
            var cookie = jQuery.trim(cookies[i]); 
            // Does this cookie string begin with the name we want? 
            if (cookie.substring(0, name.length + 1) == (name + '=')) { 
                cookieValue =  decodeURIComponent(cookie.substring(name.length + 1)); 
                break; 
            } 
        } 
    } 
    return cookieValue; 
} 
var csrftoken = getCookie('csrftoken'); 

The above code could be simplified by using the jQuery cookie plugin (http://plugins.jquery.com/cookie/) to replace getCookie:

var csrftoken = $.cookie('csrftoken'); 

Finally, you'll have to actually set the header on your AJAX request, while protecting the CSRF token from being sent to other domains using settings.crossDomain in jQuery 1.5.1 and newer:

function csrfSafeMethod(method) { 
    // these HTTP methods do not require CSRF protection 
    return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method)); 
} 
$.ajaxSetup({ 
    beforeSend: function(xhr, settings) { 
        if (!csrfSafeMethod(settings.type) && !this.crossDomain) { 
            xhr.setRequestHeader("X-CSRFToken", csrftoken); 
        } 
    } 
}); 

When using a different template engine than Django's built-in engine, you can set the token in your forms manually after making sure it's available in the template context.

For example, in the Jinja2 template language, your form could contain the following:

<div style="display:none"> 
    <input type="hidden" name="csrfmiddlewaretoken" value="{{ csrf_token }}"> 
</div> 

You can use JavaScript similar to the AJAX code above to get the value of the CSRF token.

Rather than adding CsrfViewMiddleware as a blanket protection, you can use the csrf_protect decorator, which has exactly the same functionality, on particular views that need the protection. It must be used both on views that insert the CSRF token in the output, and on those that accept the POST form data. (These are often the same view function, but not always).

Use of the decorator by itself is not recommended, since if you forget to use it, you will have a security hole. The belt and braces strategy of using both is fine, and will incur minimal overhead.

django.views.decorators.csrf.csrf_protect(view)

Decorator that provides the protection of CsrfViewMiddleware to a view.

Usage:

from django.views.decorators.csrf import csrf_protect 
from django.shortcuts import render 
 
@csrf_protect 
def my_view(request): 
    c = {} 
    # ... 
    return render(request, "a_template.html", c) 

If you are using class-based views, you can refer to Decorating class-based views.

By default, a 403 Forbidden response is sent to the user if an incoming request fails the checks performed by CsrfViewMiddleware. This should usually only be seen when there is a genuine Cross Site Request Forgery, or when, due to a programming error, the CSRF token has not been included with a POST form.

The error page, however, is not very friendly, so you may want to provide your own view for handling this condition. To do this, simply set the CSRF_FAILURE_VIEW setting.

If the csrf_token template tag is used by a template (or the get_token function is called some other way), CsrfViewMiddleware will add a cookie and a Vary: Cookie header to the response. This means that the middleware will play well with the cache middleware if it is used as instructed (UpdateCacheMiddleware goes before all other middleware).

However, if you use cache decorators on individual views, the CSRF middleware will not yet have been able to set the Vary header or the CSRF cookie, and the response will be cached without either one.

In this case, on any views that will require a CSRF token to be inserted you should use the django.views.decorators.csrf.csrf_protect() decorator first:

from django.views.decorators.cache import cache_page 
from django.views.decorators.csrf import csrf_protect 
 
@cache_page(60 * 15) 
@csrf_protect 
def my_view(request): 
    ... 

If you are using class-based views, you can refer to decorating class-based views in the Django documentation (https://docs.djangoproject.com/en/1.8/topics/class-based-views/intro/#decorating-class-based-views).

The CsrfViewMiddleware will usually be a big hindrance to testing view functions, due to the need for the CSRF token which must be sent with every POST request. For this reason, Django's HTTP client for tests has been modified to set a flag on requests which relaxes the middleware and the csrf_protect decorator so that they no longer rejects requests. In every other respect (for example, sending cookies and so on), they behave the same.

If, for some reason, you want the test client to perform CSRF checks, you can create an instance of the test client that enforces CSRF checks:

>>> from django.test import Client 
>>> csrf_client = Client(enforce_csrf_checks=True) 

Subdomains within a site will be able to set cookies on the client for the whole domain. By setting the cookie and using a corresponding token, subdomains will be able to circumvent the CSRF protection. The only way to avoid this is to ensure that subdomains are controlled by trusted users (or, are at least unable to set cookies).

Note that even without CSRF, there are other vulnerabilities, such as session fixation, that make giving subdomains to untrusted parties a bad idea, and these vulnerabilities cannot easily be fixed with current browsers.

Certain views can have unusual requirements that mean they don't fit the normal pattern envisaged here. A number of utilities can be useful in these situations. The scenarios they might be needed in are described in the following section.

The examples below assume you are using function-based views. If you are working with class-based views, you can refer to decorating class-based views in the Django documentation.

from django.views.decorators.csrf import csrf_exempt 
from django.http import HttpResponse 
 
@csrf_exempt 
def my_view(request): 
    return HttpResponse('Hello world') 

from django.views.decorators.csrf import requires_csrf_token 
from django.shortcuts import render 
 
@requires_csrf_token 
def my_view(request): 
    c = {} 
    # ... 
    return render(request, "a_template.html", c) 

from django.views.decorators.csrf import csrf_exempt, csrf_protect 
 
@csrf_exempt 
def my_view(request): 
 
    @csrf_protect 
    def protected_path(request): 
        do_something() 
 
    if some_condition(): 
       return protected_path(request) 
    else: 
       do_something_else() 

Because it is possible for the developer to turn off the CsrfViewMiddleware, all relevant views in contrib apps use the csrf_protect decorator to ensure the security of these applications against CSRF. It is recommended that the developers of other reusable apps that want the same guarantees also use the csrf_protect decorator on their views.

A number of settings can be used to control Django's CSRF behavior:

See Appendix D, Settings, for more information on each of these settings.

Suppose an online store has a page where a logged in user can click Buy Now to purchase an item. A user has chosen to stay logged into the store all the time for convenience. An attacker site might create an I Like Ponies button on one of their own pages, and load the store's page in a transparent iframe such that the Buy Now button is invisibly overlaid on the I Like Ponies button. If the user visits the attacker's site, clicking I Like Ponies will cause an inadvertent click on the Buy Now button and an unknowing purchase of the item.

Modern browsers honor the X-Frame-Options (for more information visit https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header) HTTP header that indicates whether or not a resource is allowed to load within a frame or iframe. If the response contains the header with a value of SAMEORIGIN then the browser will only load the resource in a frame if the request originated from the same site. If the header is set to DENY then the browser will block the resource from loading in a frame no matter which site made the request.

Django provides a few simple ways to include this header in responses from your site:

The X-Frame-Options header will only protect against clickjacking in a modern browser. Older browsers will quietly ignore the header and need other clickjacking prevention techniques.

For sites that should only be accessed over HTTPS, you can instruct modern browsers to refuse to connect to your domain name via an insecure connection (for a given period of time) by setting the Strict-Transport-Security header. This reduces your exposure to some SSL-stripping Man-In-The-Middle (MITM) attacks.

SecurityMiddleware will set this header for you on all HTTPS responses if you set the SECURE_HSTS_SECONDS setting to a non-zero integer value.

When enabling HSTS, it's a good idea to first use a small value for testing, for example, SECURE_HSTS_SECONDS = 3600 for one hour. Each time a web browser sees the HSTS header from your site, it will refuse to communicate non-securely (using HTTP) with your domain for the given period of time.

Once you confirm that all assets are served securely on your site (that is, HSTS didn't break anything), it's a good idea to increase this value so that infrequent visitors will be protected (31536000 seconds, that is, 1 year, is common).

Additionally, if you set the SECURE_HSTS_INCLUDE_SUBDOMAINS setting to True, SecurityMiddleware will add the includeSubDomains tag to the Strict-Transport-Security header. This is recommended (assuming all subdomains are served exclusively using HTTPS), otherwise your site may still be vulnerable via an insecure connection to a subdomain.

No bulletproof technical solution exists at the framework level to safely validate all user uploaded file content, however, there are some other steps you can take to mitigate these attacks: