---
title: "Protection contre le « Cross site request forgery » (CSRF)"
version: 1.9
locale: fr
source: https://docs.djangoproject.com/fr/1.9/ref/csrf/
canonical: https://djangodocs.dev/fr/1.9/ref/csrf/
---
# Protection contre le « Cross site request forgery » (CSRF)

L’intergiciel et les balises de gabarit CSRF permettent de se protéger facilement contre les attaques de type  [Cross Site Request Forgeries](https://www.squarefree.com/securitytips/web-developers.html#CSRF). Ce type d’attaque se produit quand un site Web malveillant contient un lien, un bouton de formulaire ou un peu de JavaScript qui est destiné à effectuer une action sur votre site Web, en utilisant les informations d’identification d’un utilisateur connecté qui visite le site malveillant dans son navigateur. Un type d’attaque liée est également couverte : celle du « login CSRF », où un site attaquant piège le navigateur d’un utilisateur en se connectant à un site avec les informations d’identification de quelqu’un d’autre.

The first defense against CSRF attacks is to ensure that GET requests (and other
“safe” methods, as defined by [**RFC 7231 Section 4.2.1**](https://datatracker.ietf.org/doc/html/rfc7231.html#section-4.2.1)) are side effect free.
Requests via “unsafe” methods, such as POST, PUT, and DELETE, can then be
protected by following the steps below.

## Comment l’utiliser

Pour profiter de la protection CSRF dans les vues, procédez comme suit :

1. L’intergiciel CSRF est activé par défaut dans le réglage [`MIDDLEWARE_CLASSES`](/fr/1.9/ref/settings/#std-setting-MIDDLEWARE_CLASSES). Si vous surchargez ce réglage, rappelez-vous que `'django.middleware.csrf.CsrfViewMiddleware'` doit figurer avant les intergiciels qui comptent sur le fait que les attaques CSRF ont déjà été contrées.

   Si vous le désactivez, ce qui n’est pas recommandé, vous pouvez utiliser [`csrf_protect()`](#django.views.decorators.csrf.csrf_protect) sur certaines vues que vous souhaitez protéger (voir ci-dessous).
2. In any template that uses a POST form, use the [`csrf_token`](/fr/1.9/ref/templates/builtins/#std-templatetag-csrf_token) tag inside
   the `<form>` element if the form is for an internal URL, e.g.:

   ```html+django
   <form action="" method="post">{% csrf_token %}
   ```

   Par contre, il ne faut pas le faire pour les formulaires POST qui ciblent des URL externes, car cela entraînerait la divulgation du jeton CSRF, et conduirait ainsi à une vulnérabilité.
3. Dans les fonctions de vue correspondantes, vérifiez que [`RequestContext`](/fr/1.9/ref/templates/api/#django.template.RequestContext) est utilisé pour produire la réponse afin que `{% csrf_token %}` fonctionne correctement. Si vous utilisez la fonction [`render()`](/fr/1.9/topics/http/shortcuts/#django.shortcuts.render), les vues génériques ou les applications contribuées, il n’y a pas de soucis à se faire car toutes ces vues utilisent `RequestContext`.

### AJAX

Même si la méthode ci-dessus peut être utilisée pour les requêtes AJAX POST, elle présente quelques inconvénients : il ne faut pas oublier de passer le jeton CSRF en même temps que les données POST à ​​chaque requête POST. Pour cette raison, il y a une autre méthode : sur chaque XMLHttpRequest, définissez un élément d’en-tête `X-CSRFToken` ayant la même valeur que le jeton CSRF. C’est souvent plus simple, parce que de nombreuses bibliothèques JavaScript fournissent des points d’extension qui permettent d’ajouter des éléments d’en-tête pour chaque requête.

En premier lieu, vous devez obtenir le jeton CSRF lui-même. La source recommandée pour le jeton est le cookie `csrftoken`, qui sera présent si vous avez activé la protection CSRF pour votre vue, comme indiqué ci-dessus.

> **Note**
>
> Le cookie CSRF est nommé `csrftoken` par défaut, mais vous pouvez modifier ce nom via le réglage [`CSRF_COOKIE_NAME`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_NAME).
>
> Le nom d’en-tête CSRF est `HTTP_X_CSRFTOKEN` par défaut, mais vous pouvez modifier ce nom via le réglage [`CSRF_HEADER_NAME`](/fr/1.9/ref/settings/#std-setting-CSRF_HEADER_NAME).

L’acquisition du jeton est simple :

```javascript
// 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');
```

Le code ci-dessus pourrait être simplifié en utilisant la [bibliothèque JavaScript Cookie](https://github.com/js-cookie/js-cookie/) pour remplacer `getCookie`:

```javascript
var csrftoken = Cookies.get('csrftoken');
```

> **Note**
>
> Le jeton CSRF est également présent dans le DOM, mais seulement s’il est explicitement inclus à l’aide de la balise [`csrf_token`](/fr/1.9/ref/templates/builtins/#std-templatetag-csrf_token) dans un gabarit. Le cookie contiendra le jeton standard ; le `CsrfViewMiddleware` préfèrera le cookie au jeton du DOM. De toute façon, vous êtes assuré d’avoir le cookie si le jeton est présent dans le DOM, il est donc préférable d’utiliser le cookie !

> **Warning**
>
> Si la vue n’utilise pas un gabarit contenant la balise [`csrf_token`](/fr/1.9/ref/templates/builtins/#std-templatetag-csrf_token), Django peut ne pas définir le cookie CSRF. Cette situation apparaît souvent dans les cas où les formulaires sont ajoutés dynamiquement à la page. Pour résoudre ce problème, Django fournit un décorateur de vue qui force l’utilisation du cookie : [`ensure_csrf_cookie()`](#django.views.decorators.csrf.ensure_csrf_cookie).

Pour terminer, il reste à effectivement définir l’en-tête sur la requête AJAX, tout en évitant que le jeton CSRF soit envoyé à d’autres domaines en utilisant [settings.crossDomain](https://api.jquery.com/jQuery.ajax) dans les versions de jQuery 1.5.1 ou plus récentes :

```javascript
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);
        }
    }
});
```

Si vous utilisez AngularJS 1.1.3 ou plus récente, il suffit de configurer le fournisseur `$http` avec les noms de cookie et d’en-tête :

```javascript
$httpProvider.defaults.xsrfCookieName = 'csrftoken';
$httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';
```

### Using CSRF in Jinja2 templates

Django’s [`Jinja2`](/fr/1.9/topics/templates/#django.template.backends.jinja2.Jinja2) template backend
adds `{{ csrf_input }}` to the context of all templates which is equivalent
to `{% csrf_token %}` in the Django template language. For example:

```html+jinja
<form action="" method="post">{{ csrf_input }}
```

### La méthode du décorateur

Plutôt que d’ajouter `CsrfViewMiddleware` comme une protection générale, vous pouvez utiliser le décorateur `csrf_protect`, qui offre exactement la même fonctionnalité, sur les vues particulières qui ont besoin de la protection. Ce décorateur doit être utilisé **à la fois** sur les vues qui insèrent le jeton CSRF dans leur rendu, et sur celles qui acceptent les données de formulaire POST. (Il s’agit souvent de la même fonction de vue, mais pas toujours).

Le recours à l’utilisation seule du décorateur **n’est pas recommandé**, car si vous oubliez de l’utiliser, vous aurez un trou de sécurité. La stratégie « ceinture et bretelles » qui consiste à utiliser les deux convient tout à fait et n’entraînera qu’une surcharge minimale.

#### `csrf_protect(view)`

Décorateur qui fournit la protection similaire à l’intergiciel `CsrfViewMiddleware` pour une vue.

Utilisation :

```
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)
```

Si vous utilisez des vues fondées sur les classes, vous pouvez vous référer à la [Décoration des vues fondées sur les classes](/fr/1.9/topics/class-based-views/intro/#id1).

## Requêtes rejetées

Par défaut, une réponse de type « 403 Forbidden » est renvoyée à l’utilisateur si une requête entrante ne satisfait pas les contrôles effectués par `CsrfViewMiddleware`. Ça ne devrait généralement apparaître que lorsqu’il s’agit d’une véritable attaque de type « Cross Site Request Forgery », ou lorsqu’en raison d’une erreur de programmation, le jeton CSRF n’a pas été inclus dans un formulaire de type POST.

La page d’erreur n’est toutefois pas très sympathique, de sorte que vous pouvez fournir votre propre vue pour traiter cette condition. Pour ce faire, il suffit de définir le réglage [`CSRF_FAILURE_VIEW`](/fr/1.9/ref/settings/#std-setting-CSRF_FAILURE_VIEW).

CSRF failures are logged as warnings to the [django.request](/fr/1.9/topics/logging/#django-request-logger)
logger.

## Fonctionnement

La protection CSRF est basée sur les éléments suivants :

1. Un cookie CSRF qui est défini à une valeur aléatoire (un nonce cryptographique indépendant de la session, comme on l’appelle), auquelle les autres sites n’auront pas accès.

   Ce cookie est créé par l’intergiciel `CsrfViewMiddleware`. Il est destiné à être permanent, mais comme il n’est pas possible d’installer un cookie qui n’expire jamais, il est envoyé avec chaque réponse qui a appelé `django.middleware.csrf.get_token()` (la fonction utilisée en interne pour récupérer le jeton CSRF).

   For security reasons, the value of the CSRF cookie is changed each time a
   user logs in.
2. Un champ de formulaire masqué avec le nom « csrfmiddlewaretoken » est présent dans tous les formulaires POST affichés. La valeur de ce champ correspond à la valeur du cookie CSRF.

   Cette action est effectuée par la balise de gabarit.
3. Pour toutes les requêtes entrantes qui n’utilisent pas les méthodes HTTP GET, HEAD, OPTIONS ou TRACE, un cookie CSRF doit être présent, et le champ « csrfmiddlewaretoken » doit être présent et correct. Si ce n’est pas le cas, l’utilisateur obtiendra une erreur 403.

   Cette vérification est effectuée par l’intergiciel `CsrfViewMiddleware`.
4. De plus, pour les requêtes HTTPS, le contrôle strict du référant est effectué par `CsrfViewMiddleware`. Cela signifie que même si un sous-domaine peut définir ou modifier des cookies pour votre domaine, il ne peut pas forcer un utilisateur à envoyer des données à votre application car cette requête ne viendrait pas de votre domaine exact.

   Cela protège aussi contre une attaque de type « Man-In-The-Middle » qui est possible sous HTTPS lors de l’utilisation d’un nonce cryptographique indépendant de la session, parce que les en-têtes HTTP `Set-Cookie` sont (malheureusement) acceptés par les clients, même quand ils parlent à un site en HTTPS. (La vérification du référant n’est pas faite pour les requêtes HTTP car la présence de l’en-tête `Referer` n’est pas suffisamment fiable sous HTTP.)

   Si le réglage [`CSRF_COOKIE_DOMAIN`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_DOMAIN) est défini, le référant est comparé avec lui. Ce réglage prend en compte les sous-domaines. Par exemple, `CSRF_COOKIE_DOMAIN = '.exemple.com'` autorise les requêtes POST depuis `www.exemple.com` et `api.exemple.com`. Si le réglage n’est pas défini, le référant doit alors correspondre à l’en-tête HTTP `Host`.

   L’extension des référants acceptés au-delà de l’hôte courant ou du domaine du cookie peut se faire avec le réglage [`CSRF_TRUSTED_ORIGINS`](/fr/1.9/ref/settings/#std-setting-CSRF_TRUSTED_ORIGINS).

Cela garantit que seuls les formulaires originaires de domaines de confiance peuvent être utilisés pour renvoyer des données avec une requête POST.

It deliberately ignores GET requests (and other requests that are defined as
“safe” by [**RFC 7231**](https://datatracker.ietf.org/doc/html/rfc7231.html)). These requests ought never to have any potentially
dangerous side effects , and so a CSRF attack with a GET request ought to be
harmless. [**RFC 7231**](https://datatracker.ietf.org/doc/html/rfc7231.html) defines POST, PUT, and DELETE as “unsafe”, and all other
methods are also assumed to be unsafe, for maximum protection.

La protection CRSF ne peut pas protéger contre les attaques de « l’homme du milieu », c’est pourquoi il faut utiliser [HTTPS](/fr/1.9/topics/security/#security-recommendation-ssl) avec [Sécurité de transport HTTP stricte (HSTS)](/fr/1.9/ref/middleware/#http-strict-transport-security). Il suppose également la [validation de l’en-tête HOST](/fr/1.9/topics/security/#host-headers-virtual-hosting) et que le site ne comporte pas de [vulnérabilités de scripts inter-sites](/fr/1.9/topics/security/#cross-site-scripting) (parce que ce type de vulnérabilité permet déjà à un attaquant de faire ce qu’une vulnérabilité CSRF permet de faire, et plus encore).

> **Changed in Django 1.9**
>
> Le contrôle en fonction du réglage [`CSRF_COOKIE_DOMAIN`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_DOMAIN) a été ajouté.

## Mise en cache

Si la balise de gabarit [`csrf_token`](/fr/1.9/ref/templates/builtins/#std-templatetag-csrf_token) est utilisée par un gabarit (ou que la fonction `get_token` est appelée d’une autre façon), l’intergiciel `CsrfViewMiddleware` ajoute un cookie et un en-tête `Vary: Cookie` à la réponse. Cela signifie que l’intergiciel fonctionnera bien avec l’intergiciel de cache s’il est utilisé conformément aux instructions (`UpdateCacheMiddleware` doit être placé dans les réglages avant tout autre intergiciel).

Toutefois, si vous utilisez des décorateurs de cache sur des vues individuelles, l’intergiciel CSRF n’aura pas encore pu définir l’en-tête Vary ou le cookie CSRF, et la réponse sera mise en cache sans l’un ni l’autre. Dans ce cas, sur les vues qui nécessitent qu’un jeton CSRF soit inséré, vous devez utiliser le décorateur de fonction [`django.views.decorators.csrf.csrf_protect()`](#django.views.decorators.csrf.csrf_protect) en premier :

```
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):
    ...
```

Si vous utilisez des vues fondées sur les classes, vous pouvez vous référer à la [Décoration des vues fondées sur les classes](/fr/1.9/topics/class-based-views/intro/#id1).

## Tests

Généralement, `CsrfViewMiddleware` gêne les tests des fonctions de vues, parce que le jeton CSRF doit être envoyé avec chaque requête POST. Le client HTTP de Django utilisé pour les tests a donc été modifié afin de marquer automatiquement les requêtes et ainsi d’informer l’intergiciel et le décorateur `csrf_protect` de manière à ce qu’ils ne rejettent pas ces requêtes. À tous les autres égards (par exemple, l’envoi des cookies, etc.), le comportement durant les tests est identique.

Si pour une raison quelconque vous *voulez* que le client HTTP utilisé pour les tests effectue des contrôles CSRF, vous pouvez créer une instance du client de test qui applique les vérifications CSRF :

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

## Limitations

Les sous-domaines d’un site peuvent placer des cookies sur le client pour l’ensemble du domaine. En définissant le cookie et en utilisant le jeton correspondant, les sous-domaines seront en mesure de contourner la protection CSRF. La seule façon d’éviter cela est de s’assurer que les sous-domaines sont contrôlés par des utilisateurs de confiance (ou, au moins ne sont pas en mesure de définir des cookies). Notez que même sans CSRF, il existe d’autres vulnérabilités, comme la fixation de session, qui font que donner des sous-domaines à des tierces parties non sûres est une mauvaise idée ; ces vulnérabilités ne peuvent pas facilement être résolues avec les navigateurs actuels.

## Cas particuliers

Certaines vues peuvent avoir des exigences inhabituelles qui impliquent qu’elles ne correspondent pas au modèle normal envisagé ici. Un certain nombre d’utilitaires peuvent être utiles dans ces situations. Les scénarios qui pourraient alors être nécessaires sont décrits dans la section suivante.

### Utilitaires

Les exemples ci-dessous s’appliquent à des vues basées sur des fonctions. Si vous utilisez des vues fondées sur les classes, vous pouvez vous référer à la [Décoration des vues fondées sur les classes](/fr/1.9/topics/class-based-views/intro/#id1).

#### `csrf_exempt(view)`

Ce décorateur marque une vue comme étant exempte de la protection assurée par l’intergiciel. Exemple :

```
from django.views.decorators.csrf import csrf_exempt
from django.http import HttpResponse

@csrf_exempt
def my_view(request):
    return HttpResponse('Hello world')
```

#### `requires_csrf_token(view)`

Normalement, la balise de gabarit [`csrf_token`](/fr/1.9/ref/templates/builtins/#std-templatetag-csrf_token) ne fonctionnera pas si  `CsrfViewMiddleware.process_view` ou un équivalent comme  `csrf_protect` n’a pas été utilisé. Le décorateur de vue `requires_csrf_token` peut être utilisé pour s’assurer que la balise de gabarit fonctionne. Ce décorateur fonctionne de façon similaire à `csrf_protect`, mais ne rejette jamais une demande entrante.

Exemple :

```
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)
```

#### `ensure_csrf_cookie(view)`

Ce décorateur force une vue à envoyer le cookie CSRF.

### Scénarios

#### La protection CSRF doit être désactivée pour quelques vues

La plupart des vues nécessitent une protection CSRF, mais quelques-unes n’en ont pas besoin.

Solution : plutôt que de désactiver l’intergiciel et d’appliquer `csrf_protect` à toutes les vues qui en ont besoin, activez l’intergiciel et utilisez [`csrf_exempt()`](#django.views.decorators.csrf.csrf_exempt).

#### CsrfViewMiddleware.process\_view non utilisé

Il y a des cas où `CsrfViewMiddleware.process_view` n’aura pas été exécuté avant votre vue - les gestionnaires d’erreurs 404 et 500, par exemple - mais vous avez quand même besoin du jeton CSRF dans un formulaire.

Solution : utilisez [`requires_csrf_token()`](#django.views.decorators.csrf.requires_csrf_token)

#### Une vue non protégée nécessite le jeton CSRF

Certaines vues peuvent ne pas être protégées, peut-être exemptées par `csrf_exempt`, mais ont tout de même besoin d’inclure le jeton CSRF.

Solution : utilisez [`csrf_exempt()`](#django.views.decorators.csrf.csrf_exempt) suivi de [`requires_csrf_token()`](#django.views.decorators.csrf.requires_csrf_token) (c’est à dire que `requires_csrf_token` doit être le décorateur le plus à l’intérieur).

#### Une vue a besoin de protection pour un chemin particulier

Une vue a besoin de protection CSRF seulement quand un certain nombre de conditions sont remplies, et ne doit pas être protégée le reste du temps.

Solution : utilisez [`csrf_exempt()`](#django.views.decorators.csrf.csrf_exempt) pour l’ensemble de la fonction de vue, et [`csrf_protect()`](#django.views.decorators.csrf.csrf_protect) spécifiquement pour le chemin qui doit être protégé. Exemple :

```
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()
```

#### Une page utilise de l’AJAX sans aucun formulaire HTML

Une page effectue une requête POST via AJAX, et cette page n’a pas de formulaire HTML avec une balise [`csrf_token`](/fr/1.9/ref/templates/builtins/#std-templatetag-csrf_token) qui provoquerait la transmission du cookie CSRF.

Solution : utilisez [`ensure_csrf_cookie()`](#django.views.decorators.csrf.ensure_csrf_cookie) sur la vue qui envoie la page.

## Applications intégrées et applications réutilisables

Comme il est possible pour le développeur de désactiver l’intergiciel `CsrfViewMiddleware`, toutes les vues concernées dans les applications « contrib » de Django utilisent le décorateur `csrf_protect` pour garantir la protection de ces applications contre les attaques CSRF. Il est recommandé que les développeurs d’autres applications réutilisables qui souhaitent offrir les mêmes garanties utilisent également le décorateur `csrf_protect` sur leurs vues.

## Réglages

Un certain nombre de réglages peuvent être utilisés pour contrôler le comportement anti-CSRF de Django :

- [`CSRF_COOKIE_AGE`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_AGE)
- [`CSRF_COOKIE_DOMAIN`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_DOMAIN)
- [`CSRF_COOKIE_HTTPONLY`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_HTTPONLY)
- [`CSRF_COOKIE_NAME`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_NAME)
- [`CSRF_COOKIE_PATH`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_PATH)
- [`CSRF_COOKIE_SECURE`](/fr/1.9/ref/settings/#std-setting-CSRF_COOKIE_SECURE)
- [`CSRF_FAILURE_VIEW`](/fr/1.9/ref/settings/#std-setting-CSRF_FAILURE_VIEW)
- [`CSRF_HEADER_NAME`](/fr/1.9/ref/settings/#std-setting-CSRF_HEADER_NAME)
- [`CSRF_TRUSTED_ORIGINS`](/fr/1.9/ref/settings/#std-setting-CSRF_TRUSTED_ORIGINS)

## Questions fréquentes

### Est-ce que l’envoi d’une paire de jetons CSRF arbitraires (cookie et données POST) est une vulnérabilité ?

Non, délibérément pas. Sans attaque de « l’homme du milieu », il n’existe aucune possibilité pour un attaquant d’envoyer un cookie de jeton CSRF à destination du navigateur de sa victime ; une attaque réussie devrait pouvoir obtenir le cookie du navigateur de la victime par XSS ou autre moyen similaire, auquel cas l’attaquant n’a généralement pas besoin d’attaquer par CSRF.

Certains outils d’audit de sécurité le signalent comme un problème, mais comme mentionné ci-dessus, un attaquant ne peut pas voler un cookie CSRF du navigateur d’un utilisateur. Pouvoir « voler » ou modifier son propre jeton à l’aide de Firebug, des outils de développement Chrome, etc. ne signifie pas qu’il s’agit d’une vulnérabilité.

### Le fait que la protection CSRF de Django n’est pas liée à une session pose-t-il un problème ?

Non, délibérément pas. Le fait de ne pas lier la protection CSRF à une session permet d’utiliser la protection sur des sites qui autorisent des envois de données par des utilisateurs anonymes et qui n’ont pas de session.

### Pourquoi ne pas utiliser un nouveau jeton pour chaque requête ?

La génération d’un nouveau jeton pour chaque requête est problématique d’un point de vue interface utilisateur car cela invalide tous les formulaires précédents. Les utilisateurs seraient très mécontents de constater que l’ouverture d’un nouvel onglet de votre site rend invalide le formulaire qu’ils viennent de remplir patiemment dans un autre onglet, ou qu’un formulaire accédé en utilisant le bouton retour ne puisse plus être rempli.

### Why might a user encounter a CSRF validation failure after logging in?

For security reasons, CSRF tokens are rotated each time a user logs in. Any
page with a form generated before a login will have an old, invalid CSRF token
and need to be reloaded. This might happen if a user uses the back button after
a login or if they log in in a different browser tab.