我最初的目標不是自我回答，但經過更多閱讀後，我想出了一個我認為是全面的答案，這也解釋了為什麼有些人仍然對REST端點上的CSRF保護感興趣。 / p>

沒有cookie =沒有CSRF

確實就是這麼簡單。瀏覽器發送cookie和所有請求。 CSRF攻擊取決於此行為。如果您不使用Cookie，並且不依賴Cookie進行身份驗證，那麼絕對沒有CSRF攻擊的空間，也沒有理由進行CSRF保護。如果您有cookie，尤其是將它們用於身份驗證，則需要CSRF保護。如果您僅想知道“我的API端點需要CSRF保護嗎？”您可以在這裡停下來並留下答案。

h / t到paj28：雖然cookie是CSRF攻擊的主要攻擊媒介，但是如果您使用HTTP / Basic，也很容易受到攻擊。身份驗證。更一般而言，如果瀏覽器能夠自動傳遞應用程序的登錄憑據，則CSRF很重要。以我的經驗，cookie是使CSRF發生的最常用技術，但是使用其他一些身份驗證方法也可能導致相同的漏洞。

REST =無狀態

如果您問某人“什麼是REST”，您將獲得討論各種不同屬性的各種答案。您可以看到很多，因為有人在堆棧溢出時問了這個問題： https://stackoverflow.com/questions/671118/what-exactly-is-restful-programming

我一直依賴的REST的一個屬性是它是無狀態的。應用程序本身俱有狀態。如果您無法將數據存儲在某個地方的數據庫中，則您的應用程序將受到很大限制。但是，在這種情況下，無狀態具有非常具體且重要的含義：REST應用程序不會跟踪客戶端應用程序的狀態。如果您正在使用會話，那麼（幾乎可以肯定）您正在跟踪客戶端狀態，並且您不是REST完整的應用程序。因此，使用通過cookie跟踪的會話（尤其是登錄名）的應用程序不是REST-full應用程序（IMO），並且即使看起來像REST應用程序，也很容易受到CSRF攻擊。

Rest≠Cookieless

由於這些原因，我最初認為完全兼容的REST應用程序將永遠不需要會話，不需要Cookie，因此也不需要CSRF安全性。但是，至少有一個用例仍然喜歡使用cookie：持久登錄。

考慮一個典型的客戶端（在這種情況下為瀏覽器，而不是移動設備）Web應用程序。從登錄開始，登錄使用REST API來驗證用戶憑據，作為回報，將獲得一個令牌來授權將來的請求。對於單頁應用程序，您可以只將該令牌保留在內存中，但是這樣做會在用戶關閉頁面時有效地註銷用戶。因此，最好將狀態保持在比單個瀏覽器會話持續時間更長的位置。本地存儲是一種選擇，但也容易受到XSS攻擊：成功的XSS攻擊可能導致攻擊者獲取您的登錄令牌並將其發送給攻擊者，以供其自行決定。

為此，原因，我已經看到一些建議使用Cookie來存儲登錄令牌。使用cookie可以設置僅http標誌，這將阻止應用程序在設置cookie後讀取它。因此，在發生XSS攻擊時，攻擊者仍可以代表您撥打電話，但他們無法一起擺脫授權令牌。 Cookie的這種使用不會直接違反REST的無狀態要求，因為服務器仍未跟踪客戶端狀態。

我之所以提及這一點，是因為使用cookie與REST API一起使用可能是合理的理由，儘管它顯然取決於給定的應用程序平衡各種安全性和可用性問題。我個人會嘗試避免將cookie與REST API一起使用，但是很可能還是有理由使用它們。無論哪種方式，總的答案都很簡單：如果您使用Cookie（或瀏覽器可以自動執行的其他身份驗證方法），則需要CSRF保護。如果您不使用Cookie，那麼您就不會使用。

”“即使通過某種方式誘使瀏覽器訪問了API端點，瀏覽器也無法自動提供身份驗證憑據” Windows / Kerberos身份驗證。在這種情況下，如果配置為這樣做，則瀏覽器將自動提供憑據（kerberos或NTLM令牌）。

所以-我相信在這種情況下，需要CSRF。

是否需要CSRF保護基於兩個因素：-

請求是否在執行狀態更改操作（與REST API無狀態不同）-狀態更改動作是將更改應用程序狀態的任何動作。例如，刪除某些內容，添加某些內容，更新某些內容。這些是應用程序用來更改用戶支持狀態的操作。所有“發帖”請求和一些“獲取”請求將屬於此類別。 REST API可以具有狀態更改操作。

是瀏覽器提供的身份驗證（不限於Cookie）-CSRF之所以發生，是因為瀏覽器在請求中包含了身份驗證信息，而不管是否該請求是由用戶或其他打開的標籤頁啟動的。因此，瀏覽器可以自我包含信息的任何身份驗證都需要CSRF保護。這包括基於cookie的會話和基本身份驗證。

對於屬於以上2類的所有請求，都需要CSRF保護。

我想在其他答案中添加的一件事是，在所涉及的cookie的域和路徑中，僅 b>才需要CSRF保護。或換種說法：

授權！=身份驗證
Cookies ==身份驗證
令牌==授權

這與持久性登錄的實現有關（您的第三點）。如果將Cookie附加到託管登錄UI和 / authorize 端點的 login.example.com 上，則可以每隔幾分鐘運行一次隱式OAuth流，而無需一個新的登錄名（例如無密碼對話框）。客戶端無需CSRF即可繼續將如此獲取的訪問令牌發送到 api.example.com ，因為不會將Cookie發送到該主機。

因此，您仍然可以安全地避免在您的REST API上處理CSRF。但是您的登錄/身份驗證服務器最好是防彈的（並受CSRF保護）。

Rest API端點與其他請求有一​​個非常重要的區別：它們特別是無狀態的，絕不應該接受/使用cookie或會話中的數據。

如果這是定義“ REST API”的方式，則不可能使用CSRF。 CSRF，也稱為“會話騎馬” [ citation]，如果沒有要“騎馬”的會話，顯然將不起作用。

答案：如果將令牌存儲在localStorage中並使用JS將其附加到您的請求中，它將自動保證CSRF保護（根據攻擊的性質）

附錄：關於使用僅使用HTTP的cookie而不是localStorage是否更安全（在XSS的情況下，使用CSRF保護的方式似乎會產生問題）：實際上不是。對於通過漏洞利用XSS來控制您網站上JS的攻擊者來說，這只會變得有點困難。@ bobince用更好的話解釋道：設置httponly是否可以防止使用XSS竊取會話？

XSS是應用程序級別的漏洞，但可以通過使用聲明限制使用令牌的能力（將其限制為最低限度）來減輕其影響

對於我想添加的現有答案，有一個小的特定警告。儘管Conor認為Cookie是沿著所有請求發送的本地存儲身份驗證數據的唯一形式是正確的，但它們並不是網站使用的本地存儲身份驗證數據的唯一形式。這意味著，如果站點決定將其JWT /會話令牌保留在LocalStorage或SessionStorage之類的內容中，則有時仍可以通過javascript自動將其刪除，然後在無需用戶交互的情況下使用它們。這意味著有時仍然可以通過將用戶重定向到 then 發送憑據的域匹配前端URI來執行“一旦刪除” CSRF攻擊。如果您已經反映了XSS，則可以通過更直接的方式來完成此操作，但是在某些情況下，這是不必要的，並且此類頁面和腳本已經存在。

在這些情況下，問題不是出在REST API上缺少CSRF令牌。不管與之交互的任何前端，端點上都沒有令牌。