我有一個安全的網站，要求用戶進行身份驗證，並希望從我的API通過JSON-P返回敏感數據到客戶端，以便我可以避開ajax跨域的問題。我擁有客戶端和服務器，所以我不關心客戶端的安全性（即從服務器讀取惡意的js）。JSON-P與敏感信息的使用
我一直在研究如何保護JSON-P以防止跨站點請求僞造，但一直未能清楚地確定檢查Referer是否是保護數據安全的方法。據我瞭解，在這種情況下Referer標題不能被欺騙，因爲調用將來自javascript，並且標題不能更改。這是一個正確的假設嗎？
我想知道爲什麼或爲什麼不檢查Referer是否會無法保護JSON-P，這些清晰的例子。
謝謝！
編輯：
只是爲了澄清 - 的JSON-P是通過Spring Security的安全，所以它不會只由Referer標頭擔保。我主要關心會話劫持...
Jsonp網址可以使用普通捲曲代碼進行調用。 http引用很容易被僞造。
是的，但是如果您從普通客戶端調用JSON-P，那麼您必須首先進行身份驗證，因此我認爲curl不會起作用。有人可以獲取不應該訪問的數據的唯一方法是劫持現有會話，然後欺騙引用者，我認爲這將通過Javascript。 – acvcu
@acvcu這是否意味着該網址在登錄時包含某種會話信息？ – user123444555621
不，URL本身在登錄時沒有任何會話信息。它使用JSESSIONID cookie。 – acvcu
我想知道爲什麼或爲什麼不檢查Referer會不會工作來保護JSON-P的一些明確的例子。
Referer不能保證被髮送出去：
，如果你需要它存在並匹配受信任的站點，你會被打破了大家的應用程序，其瀏覽器或網絡設置沒有按發送它;如果你允許它不存在以解決這個問題，你打開自己的攻擊不僅僅是爲了那些用戶，而是針對每個攻擊者可以誘使Referer不被髮送的人（最明顯的是，來自HTTPS頁面;
也與代理正常，你就必須no-cache所有的反應（或Vary: Referer，但不會正確的工作在IE）
介紹人檢查是一個軟弱和問題方法，有時候把它看作絕望的最後一個措施......這不是你應該做的當你有選擇的時候。如果您控制兩臺服務器，則可以輕鬆地將請求令牌包含在一個頁面上，並由腳本識別。
您應該查看OAuth，它基本上採用了使用簽名令牌進一步檢查引薦者的想法。 – user123444555621
我考慮過OAuth，它可能會讓我們使用JSON（而不是'with padding'）。目前我們正在使用CAS，我想使用它，但到目前爲止，它只是一個試圖讓它與AJAX調用一起工作以獲得純JSON的熊。 – acvcu