搭配 AJAX 使用 CSRF 保護¶

雖然上述方法可用於 AJAX POST 請求，但有一些不便之處：你必須記得在每次 POST 請求中將 CSRF 權杖當作 POST 資料傳遞。因此，有一種替代方法：在每個 XMLHttpRequest 上，將自訂的 X-CSRFToken 標頭（如 CSRF_HEADER_NAME 設定所指定）設為 CSRF 權杖的值。這通常比較容易，因為許多 JavaScript 框架都提供允許在每個請求上設定標頭的 Hook。

首先，你必須取得 CSRF 權杖。如何取得取決於是否啟用 CSRF_USE_SESSIONS 和 CSRF_COOKIE_HTTPONLY 設定。

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');

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

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

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) {
    // ...
});

在 Jinja2 模板中使用 CSRF 保護¶

Django 的 Jinja2 模板後端會將 {{ csrf_input }} 新增至所有模板的內容中，這相當於 Django 模板語言中的 {% csrf_token %}。例如：

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

使用裝飾器方法¶

你可以在需要保護的特定視圖上使用 csrf_protect() 裝飾器，而不是全面性地新增 CsrfViewMiddleware 作為保護，其功能完全相同。它必須 **同時** 用於在輸出中插入 CSRF 權杖的視圖，以及接受 POST 表單資料的視圖。（這些通常是同一個視圖函式，但不總是如此）。

**不建議** 單獨使用裝飾器，因為如果你忘記使用它，就會出現安全漏洞。「雙重保護」策略，也就是同時使用兩者是可以的，而且只會產生極少的額外負擔。

處理遭拒絕的請求¶

預設情況下，如果傳入的請求未能通過 CsrfViewMiddleware 執行的檢查，則會向使用者傳送「403 Forbidden」回應。通常只有在發生真正的跨站請求偽造，或是因為程式設計錯誤而未在 POST 表單中包含 CSRF 權杖時才會看到此狀況。

但是，錯誤頁面不是很友善，因此你可能會想要提供自己的視圖來處理這種情況。若要這麼做，請設定 CSRF_FAILURE_VIEW 設定。

CSRF 失敗會以警告的形式記錄到 django.security.csrf 記錄器。

搭配快取使用 CSRF 保護¶

如果範本使用了 csrf_token 範本標籤（或以其他方式呼叫了 get_token 函式），CsrfViewMiddleware 會在回應中加入 cookie 和 Vary: Cookie 標頭。這表示如果按照指示使用（UpdateCacheMiddleware 位於所有其他中介軟體之前），此中介軟體會與快取中介軟體良好協作。

但是，如果您在個別的視圖上使用快取裝飾器，CSRF 中介軟體將尚未能設定 Vary 標頭或 CSRF cookie，而且回應將在沒有任何一個的情況下被快取。在這種情況下，對於任何需要插入 CSRF 令牌的視圖，您應該首先使用 django.views.decorators.csrf.csrf_protect() 裝飾器。

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

如果您正在使用基於類的視圖，您可以參考 裝飾基於類的視圖。

測試與 CSRF 保護¶

由於每個 POST 請求都必須傳送 CSRF 令牌，因此 CsrfViewMiddleware 通常會成為測試視圖函式的巨大障礙。因此，Django 的 HTTP 測試用戶端已修改為在請求上設定一個標記，此標記會放寬中介軟體和 csrf_protect 裝飾器的限制，使它們不再拒絕請求。在其他方面（例如傳送 cookie 等），它們的行為方式相同。

如果由於某些原因，您 *想要* 測試用戶端執行 CSRF 檢查，您可以建立一個強制執行 CSRF 檢查的測試用戶端實例。

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

邊緣案例¶

某些視圖可能具有不尋常的需求，這表示它們不符合此處預期的正常模式。在這些情況下，許多公用程式可能很有用。以下章節將說明可能需要它們的情況。

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

可重複使用應用程式中的 CSRF 保護¶

由於開發人員可以關閉 CsrfViewMiddleware，因此 contrib 應用程式中的所有相關視圖都使用 csrf_protect 裝飾器，以確保這些應用程式的安全性不受 CSRF 影響。建議其他想要相同保證的可重複使用應用程式的開發人員也在其視圖上使用 csrf_protect 裝飾器。