# Django 6.0.7 documentation

# Så här använder du Djangos CSRF-skydd

Följ dessa steg för att dra nytta av CSRF-skydd i dina vyer:

1. The CSRF middleware is activated by default in the `MIDDLEWARE` setting. If you override that setting, remember that `'django.middleware.csrf.CsrfViewMiddleware'` should come before any view middleware that assumes that CSRF attacks have been dealt with.

   Om du inaktiverar det, vilket inte rekommenderas, kan du använda `csrf_protect()` på särskilda vyer som du vill skydda (se nedan).

2. I alla mallar som använder ett POST-formulär ska du använda taggen `csrf_token` inuti elementet `<form>` om formuläret är för en intern URL, t.ex:

       <form method="post">{% csrf_token %}

   Detta bör inte göras för POST-formulär som riktar sig till externa webbadresser, eftersom det skulle leda till att CSRF-token läcker ut, vilket leder till en sårbarhet.

3. I motsvarande vyfunktioner ska du se till att `RequestContext` används för att rendera svaret så att `{% csrf_token %}` fungerar korrekt. Om du använder `render()`-funktionen, generiska vyer eller Contrib-appar, är du redan täckt eftersom dessa alla använder `RequestContext`.

## Använda CSRF-skydd med AJAX

Även om ovanstående metod kan användas för AJAX POST-begäranden har den vissa nackdelar: du måste komma ihåg att skicka CSRF-token som POST-data vid varje POST-begäran. Av denna anledning finns det en alternativ metod: på varje XMLHttpRequest, ställ in en anpassad `X-CSRFToken` header (som anges av inställningen `CSRF_HEADER_NAME`) till värdet av CSRF-token. Detta är ofta enklare eftersom många JavaScript-ramverk tillhandahåller hooks som gör det möjligt att ställa in rubriker vid varje begäran.

Först måste du hämta CSRF-token. Hur du gör det beror på om inställningarna `CSRF_USE_SESSIONS` och `CSRF_COOKIE_HTTPONLY` är aktiverade eller inte.

### Förvärvar token om `CSRF_USE_SESSIONS` och `CSRF_COOKIE_HTTPONLY` är `False`

Den rekommenderade källan för token är cookien `csrftoken`, som kommer att ställas in om du har aktiverat CSRF-skydd för dina vyer enligt beskrivningen ovan.

CSRF-token-cookien heter som standard `csrftoken`, men du kan styra cookienamnet via inställningen `CSRF_COOKIE_NAME`.

Du kan förvärva token så här:

    function getCookie(name) {
        let cookieValue = null;
        if (document.cookie && document.cookie !== '') {
            const cookies = document.cookie.split(';');
            for (let i = 0; i < cookies.length; i++) {
                const cookie = cookies[i].trim();
                // 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;
    }
    const csrftoken = getCookie('csrftoken');

Ovanstående kod kan förenklas genom att använda JavaScript Cookie library för att ersätta `getCookie`:

    const csrftoken = Cookies.get('csrftoken');

Observera

CSRF-token finns också i DOM:en i maskerad form, men endast om den uttryckligen inkluderas med `csrf_token` i en mall. Cookien innehåller den kanoniska, omaskerade token. `CsrfViewMiddleware` accepterar båda. För att skydda mot BREACH-attacker rekommenderas det dock att använda en maskerad token.

Varning

Om din vy inte renderar en mall som innehåller `csrf_token` malltagg, kanske Django inte ställer in CSRF-token-cookien. Detta är vanligt i fall där formulär dynamiskt läggs till på sidan. För att ta itu med detta fall tillhandahåller Django en vydekorator som tvingar inställningen av cookien: `ensure_csrf_cookie()`.

### Förvärvar token om `CSRF_USE_SESSIONS` eller `CSRF_COOKIE_HTTPONLY` är `True`

Om du aktiverar `CSRF_USE_SESSIONS` eller `CSRF_COOKIE_HTTPONLY` måste du inkludera CSRF-token i din HTML och läsa token från DOM med JavaScript:

    {% csrf_token %}
    <script>
    const csrftoken = document.querySelector('[name=csrfmiddlewaretoken]').value;
    </script>

### Ställa in token på AJAX-begäran

Slutligen måste du ställa in rubriken på din AJAX-begäran. Använda API:et fetch():

    const request = new Request(
        /* URL */,
        {
            method: 'POST',
            headers: {'X-CSRFToken': csrftoken},
            mode: 'same-origin' // Do not send CSRF token to another domain.
        }
    );
    fetch(request).then(function(response) {
        // ...
    });

## Använda CSRF-skydd i Jinja2-mallar

Djangos `Jinja2` mallbackend lägger till `{{ csrf_input }}` i kontexten för alla mallar, vilket motsvarar `{% csrf_token %}` i Djangos mallspråk. Till exempel:

    <form method="post">{{ csrf_input }}

## Använda dekorationsmetoden

I stället för att lägga till `CsrfViewMiddleware` som ett allmänt skydd kan du använda `csrf_protect()`-dekoratorn, som har exakt samma funktionalitet, på särskilda vyer som behöver skyddet. Den måste användas både på vyer som infogar CSRF-token i utdata och på de som accepterar POST-formulärdata. (Dessa är ofta samma vyfunktion, men inte alltid).

Det är inte att rekommendera att använda dekoratorn ensam, eftersom det finns ett säkerhetshål om man glömmer att använda den. Strategin med att använda båda är bra och medför minimalt med overhead.

## Hantering av avvisade förfrågningar

Som standard skickas ett ”403 Forbidden”-svar till användaren om en inkommande begäran inte klarar de kontroller som utförs av `CsrfViewMiddleware`. Detta bör vanligtvis bara ses när det finns en äkta Cross Site Request Forgery, eller när CSRF-token på grund av ett programmeringsfel inte har inkluderats i ett POST-formulär.

Felsidan är dock inte särskilt användarvänlig, så du kanske vill skapa en egen vy för att hantera detta tillstånd. Detta gör du genom att ange inställningen `CSRF_FAILURE_VIEW`.

CSRF-misslyckanden loggas som varningar till loggern django.security.csrf.

## Använda CSRF-skydd med cachelagring

Om malltaggen `csrf_token` används av en mall (eller om funktionen `get_token` anropas på något annat sätt), kommer `CsrfViewMiddleware` att lägga till en cookie och en `Vary: Cookie` till svaret. Detta innebär att mellanvaran kommer att fungera bra tillsammans med cache-mellanvaran om den används enligt instruktionerna (`UpdateCacheMiddleware` går före alla andra mellanvaror).

Men om du använder cachedekoratorer på enskilda vyer kommer CSRF-mellanvaran ännu inte att ha kunnat ställa in Vary-huvudet eller CSRF-cookien, och svaret kommer att cachas utan någon av dem. I det här fallet bör du på alla vyer som kräver att en CSRF-token infogas använda `django.views.decorators.csrf.csrf_protect()`-dekoratorn först:

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

Om du använder klassbaserade vyer kan du läsa Dekorera klassbaserade vyer.

## Testning och CSRF-skydd

`CsrfViewMiddleware` kommer vanligtvis att vara ett stort hinder för att testa vyfunktioner, på grund av behovet av CSRF-token som måste skickas med varje POST-begäran. Av denna anledning har Djangos HTTP-klient för tester modifierats för att ställa in en flagga på förfrågningar som slappnar av mellanvaran och dekoratorn `csrf_protect` så att de inte längre avvisar förfrågningar. I alla andra avseenden (t.ex. skicka cookies etc.) beter de sig likadant.

Om du av någon anledning vill att testklienten ska utföra CSRF-kontroller kan du skapa en instans av testklienten som verkställer CSRF-kontroller:

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

## Kantfall

Vissa vyer kan ha ovanliga krav som innebär att de inte passar in i det normala mönstret som beskrivs här. Ett antal verktyg kan vara användbara i dessa situationer. De scenarier där de kan behövas beskrivs i följande avsnitt.

### Inaktivera CSRF-skydd för bara ett fåtal visningar

De flesta visningar kräver CSRF-skydd, men några gör det inte.

Lösning: Istället för att inaktivera middleware och tillämpa `csrf_protect` på alla vyer som behöver det, aktivera middleware och använd `csrf_exempt()`.

### Ställa in token när `CsrfViewMiddleware.process_view()` inte används

Det finns fall där `CsrfViewMiddleware.process_view` kanske inte har körts innan din vy körs - 404- och 500-hanterare, till exempel - men du behöver fortfarande CSRF-token i ett formulär.

Lösning: använd `requires_csrf_token()`

### Inkludera CSRF-token i en oskyddad vy

Det kan finnas vissa vyer som är oskyddade och har undantagits med `csrf_exempt`, men som ändå måste innehålla CSRF-token.

Lösning: använd `csrf_exempt()` följt av `requires_csrf_token()`. (dvs. `requires_csrf_token` bör vara den innersta dekoratorn).

### Skyddar en vy för endast en väg

En vy behöver CSRF-skydd endast under en uppsättning villkor, och får inte ha det under resten av tiden.

Lösning: använd `csrf_exempt()` för hela vyfunktionen, och `csrf_protect()` för sökvägen inom den som behöver skyddas. Exempel:

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

### Skydda en sida som använder AJAX utan HTML-formulär

En sida gör en POST-begäran via AJAX, och sidan har inte ett HTML-formulär med en `csrf_token` som skulle göra att den nödvändiga CSRF-cookien skickas.

Lösning: använd `ensure_csrf_cookie()` på den vy som skickar sidan.

## CSRF-skydd i återanvändbara applikationer

Eftersom det är möjligt för utvecklaren att stänga av `CsrfViewMiddleware` använder alla relevanta vyer i Contrib-appar `csrf_protect`-dekoratorn för att garantera säkerheten för dessa applikationer mot CSRF. Det rekommenderas att utvecklare av andra återanvändbara appar som vill ha samma garantier också använder dekoratorn `csrf_protect` på sina vyer.