我試圖找出是否有防止CSRF嵌入式客戶的網站一個JavaScript控件的好方法。如何可靠地保護公共JSONP請求？
這個小部件將使最終用戶能夠通過JSONP向我們客戶的賬戶發送一個請求給我們（非公共）API的PHP服務器。
到目前爲止，我還沒有想出一個絕對的方法來確保所有請求都來自我們客戶的網站。有些想法我有：在服務器端生成並與每個後續JSONP請求一起（不知道如何驗證，雖然初始請求，因爲第一個令牌將在JS和任何人是可讀的回傳
這是在所有可能的？我已經遇到Fotomoto's widget這似乎讓同一類型的，我們正在尋找的功能，但我不知道他們是如何做的。
您永遠不會找到一種解決方案，確保來自隨機第三方（用戶）的請求實際上是通過訪問您客戶的網站發起的。如果您的安全依賴於此，那麼您必須刪除該假設。 （如果你真的是「確保請求只從客戶的網站來了」 服務器那麼這是微不足道的。SSL使用客戶端證書，但我相信你的意思是「從隨機用戶的機器來，意圖用我們的客戶的網站「。）
你應該尋找如何防止用戶被欺騙（CSRF）。舉例來說，Referer可能被欺騙的事實與這個問題無關。唯一的問題是，是否有一個瀏覽器有一個缺陷，可以讓第三方誘騙用戶創建欺騙引用者。所以你應該檢查Referer是必要的，但不夠。也就是說，如果Referer錯誤，掛斷呼叫者。但Referer正確的事實並不意味着你實際上收到了合法的請求。我認爲大多數CSRF是由於未能檢查Referer而不是瀏覽器錯誤。
Wikipedia article on CSRF有一個體面的總結顯而易見的預防技術。只需檢查Referer是第一步。
根據定義，這是一個「跨站點請求」。請注意，CSRF請求是否是漏洞很大程度上取決於請求的功能。例如，如果攻擊者可以強制客戶端發出搜索請求，那麼這可能對攻擊者沒有任何用處。如果攻擊者可以更改管理員的密碼，那麼你有一個非常嚴重的問題。
所以不知道這些請求是做什麼的，不可能說它應該如何保護。話雖這麼說，我認爲reCapthca是如何非對稱加密技術可以用來保證服務器授權客戶的翻譯與第三方一個很好的例子。但沒有更多的信息，我不知道這可以如何幫助你。