我正在開發一個Web應用程序，其中所有動態內容都作爲JSON與Ajax請求一起檢索。我正在考慮是否應該保護來自不同來源的GET API調用？是否需要CSRF保護免於副作用的GET請求？
GET請求不會修改狀態，普遍的看法是它們不需要CSRF保護。但是，我想知道是否沒有哪個瀏覽器將這些請求的結果泄漏到不同的原始網站？例如，如果一個不同的起源站點GET/users/emails爲腳本，css或img，瀏覽器是否有可能將結果json泄漏到調用站點（例如，通過javascript onerror handler）？
Do瀏覽器是否提供了足夠強的保證，以確保跨源JSON響應的內容不會泄露？你是否認爲保護GET請求不受跨源數據調用是有意義的，還是它是矯枉過正的？
你已經釘了一個角落案件，但高度相關的問題。事實上，有這種可能性，它被稱爲JSON包含或跨站點腳本包含或Javascript包含，這取決於你所指的人。基本上，攻擊是在一個邪惡的網站上進行的，然後通過JavaScript訪問結果，一旦js引擎解析了它。
簡言之，您的所有JSON響應都必須包含在對象中，而不是數組或JSONP（如此：{...}），爲了更好地衡量您應該使用前綴開始所有響應（while（ 1），用於（;;）或解析器斷路器）。查看Facebook或Google的JSON響應以獲得實例。 或者，您可以通過使用CSRF保護使您的URL無法推測 - 兩種方法都可行。
號：
這不是一個CSRF問題，只要你返回純JSON和您的GET的是側面影響自由的，它並沒有被CSRF保護。
Paradoxengine提到的是另一個漏洞：如果您使用的是JSONP，那麼JSON會發送給經過身份驗證的用戶的possible for an attacker to read。即使使用普通的JSON，用戶也很老（IE 5.5）can also be attacked in this way。
您可以將請求發送到不同的域（這是CSRF攻擊所做的），但無法讀取響應。
我從這裏學到了另一個堆棧溢出問題It seems like I understand CSRF incorrectly? 希望這可以幫助你理解問題。
是*所有*請求*保證*是副作用免費，或者你也有Ajax請求修改狀態？這樣計劃嗎？如果出現這種情況，無論如何我都會加以防範，只要統一API即可。 – Creshal
是的，應用程序使用POST，PUT和DELETE請求修改狀態，這些顯然需要CSRF保護。 –