Para aproveitar das vantagens da proteção CSRF nas suas views, siga estes passos:
\nO middleware CSRF está ativado por padrão na configuração MIDDLEWARE. Se você sobrescrever esta configuração, lembre-se que 'django.middleware.csrf.CsrfViewMiddleware' deve vir antes do que qualquer middleware de view que assuma que ataques CSRF já tenham sido resolvidos.
Se você o desabilitou, o que não é recomendado, você pode usar csrf_protect() em views especifícas que você deseja proteger (veja abaixo).
Em qualquer template que usa um formulário POST, use a tag csrf_token dentro do 1 elemento se o formulário é para uma URL interna, por exemplo:
<form method="post">{% csrf_token %}\nIsso não deve feito para formulários POST para URLs externas, já que isso causaria o vazamento do token CSRF, levando a uma vulnerabilidade.
\nNas devidas funções de view, garanta que RequestContext é utilizado para renderizar a resposta, assim {% csrf_token %} irá funcionar como o esperado. Se você está usando a função render(), views genéricas, ou apps contrib, você não precisa fazer isso, já que todas essas já fazem uso do RequestContext.
Mesmo que o método acima possa ser utilizado para requisições POST AJAX, existem algumas incoveniências: você precisa se lembrar de passar o token CSRF nos dados de POST em todas as requisições POST. Por esse motivo existe um método alternativo: Em cada XMLHttpRequest, defina um cabeçalho customizado X-CSRFToken (como especificado pela configuração CSRF_HEADER_NAME) com o valor do token CSRF. Isso geralmente é mais fácil por que muitos frameworks Javascript dão hooks que permitem que cabeçalhos sejam definidos em toda requisição.
Primeiro, você precisa pegar o token CSRF. Como fazer isso depende das configurações CSRF_USE_SESSIONS e CSRF_COOKIE_HTTPONLY estarem habilitadas.
Finalmente, você precisará definir o cabeçalho na sua requisição AJAX. Using a API fetch():
\nconst request = new Request(\n /* URL */,\n {\n method: 'POST',\n headers: {'X-CSRFToken': csrftoken},\n mode: 'same-origin' // Do not send CSRF token to another domain.\n }\n);\nfetch(request).then(function(response) {\n // ...\n});\nO backend de template Jinja2 do Django adiciona {{ csrf_input }} para o contexto de todos os templates que é equivalente ao {% csrf_token %} na linguagem de template do Django. Por exemplo:
<form method="post">{{ csrf_input }}\nEm vez de adicionar CsrfViewMiddleware como uma proteção geral, você pode usar o decorador csrf_protect(), que tem exatamente a mesma funcionalidade, em views específicas que precisem de proteção. É necessário usá-lo tanto nas views que inserem o token CSRF na sua saída, quanto aquelas que aceitem dados de um formulário POST. (Geralmente essas duas estão na mesma função de view, mas não necessariamente).
O uso apenas do decorador não é recomendado, já que se você se esquecer de usá-lo, você pode ter uma brecha de segurança. A estratégia de usar ‘Cinto e suspensório’ é aceitável, e traz consequências mínimas.
\nPor padrão, uma resposta ‘403 Proibido’ é enviada para o usuário caso a requisição recebida falhe nas verificações feitas pelo CsrfViewMiddleware. Geralmente isso é apenas visto quando realmente há um Cross Site Request Forgery, ou quando devido um erro de programação, o token CSRF não é incluído junto do formulário POST.
A página de erro, porém, não é muito amigável, então você pode definir sua própria view para lidar com esta condição. Para fazer isso, defina a configuração CSRF_FAILURE_VIEW.
Falhas CSRF são logadas como aviso pelo logger django.security.csrf.
\nSe a tag de template csrf_token é usado por um template (ou a função get_token é chamada de um outro jeito), o CsrfViewMiddleware adicionará o cookie e um cabeçalho Vary: Cookie para a resposta. Isso significa que o middleware irá funcionar com o middleware de cachê se usado conforme instruído (UpdateCacheMiddleware deve vir antes de qualquer outro middleware).
Porém, se você usar decoradores de cachê em views individuais, o middleware de CSRF não será capaz de definir o cabeçalho Vary ou o cookie CSRF, e a resposta será cacheada sem nenhum deles. Nesse caso, quaisquer views que precisem que um token CSRF seja inserido você deve usar o decorador django.views.decorators.csrf.csrf_protect() primeiro:
from django.views.decorators.cache import cache_page\nfrom django.views.decorators.csrf import csrf_protect\n\n\n@cache_page(60 * 15)\n@csrf_protect\ndef my_view(request):\n ...\nSe você está usando class-based views, você pode se referir à Decorating class-based views.
\nO CsrfViewMiddleware normalmente será um grande obstáculo para testar as funções view, devido a necessidade do token CSRF estar presente em toda requisição POST. Por isso, o cliente HTTP de testes do Django foi modificado para definir uma flag nas requisições que relaxam o middleware e o decorador csrf_protect para que eles não rejeitem as requisições. Em todos outros casos (por exemplo enviando cookies etc.), eles se comportam da mesma maneira.
Se, por algum motivo, você quer que o cliente de teste realize as verificações CSRF, você pode criar uma instância do cliente de teste que força as verificações CSRF:
\n>>> from django.test import Client\n>>> csrf_client = Client(enforce_csrf_checks=True)\nAlgumas views podem ter requisitos incomuns que não se encaixam nos padrões demonstrados aqui. Algumas ferramentas podem ser úteis nessas situações. Os cenários em que elas podem ser necessárias estão descritos nesta seção.
\nA maioria das views precisam de proteção CSRF, mas algumas não.
\nSolução: Em vez de desabilitar o middleware e aplicar csrf_protect para todas as views que precisam, habilite o middleware e use csrf_exempt().
CsrfViewMiddleware.process_view() não é utilizadoLink para este cabeçalho#Existem casos onde CsrfViewMiddleware.process_view pode não ter sido executado antes da sua view - os handlers 404 e 500, por exemplo - Mas você ainda precisa de um token CSRF em um formulário.
Solução: use requires_csrf_token()
Podem existir algumas views que são desprotegidas e foram exceções pelo csrf_exempt, mas ainda precisam incluir um token CSRF.
Solução: use csrf_exempt() seguido do requires_csrf_token(). (ou seja requires_csrf_token precisa ser o decorador mais próximo da função).
Uma view precisa da proteção CSRF apenas sob algumas condições, e pode não precisar em outras.
\nSolução: use csrf_exempt() para toda a função da view, e csrf_protect() para o caminho interno que precisa de proteção. Exemplo:
from django.views.decorators.csrf import csrf_exempt, csrf_protect\n\n\n@csrf_exempt\ndef my_view(request):\n @csrf_protect\n def protected_path(request):\n do_something()\n\n if some_condition():\n return protected_path(request)\n else:\n do_something_else()\nUma página faz uma requisição POST por AJAX, e a página não contém um formulário HTML com um csrf_token que irá causar que o cookie de CSRF obrigatório seja enviado.
Solução: use ensure_csrf_cookie() não view que envia a página.
Já que é possível para o desenvolvedor desligar o CsrfViewMiddleware, todas as views relevantes nos apps contrib usam o decorador csrf_protect para garantir a segurançar destas aplicações contra CSRF. É recomendado que os desenvolvedores de apps reutilizáveis que querem as mesmas garantias também usem o decorador csrf_protect nas suas views.