主要的是：

• 在整個站點範圍內使用SSL。請勿通過http提供任何內容。相反，通過http進行的任何連接都應立即通過https重定向到主站點的登錄頁面。

• 使用HTTPS嚴格傳輸安全性。這將告訴用戶瀏覽器：請僅通過https與我連接。這樣可以抵禦sslstrip和類似的中間人攻擊。

• 在所有cookie上設置安全標誌。這將確保cookie只會通過https通道發送，絕不會通過不安全的http鏈接發送。

• 避免通過http提供第三方有效內容。通過http加載外部活動內容。確保從第三方來源加載的所有CSS，Javascript，窗口小部件，分析或廣告均通過https加載。

  • 可能更好，您可以考慮自己製作如果可能，請從您自己的服務器複製並提供這些資源，因此您無需從第三方來源加載它們。在許多情況下，只需將副本存儲在自己的服務器上，就可以避免從第三方來源加載CSS，JavaScript庫或窗口小部件。

  • 對於分析，請注意，Google Analytics（分析）確實支持https。

  • 廣告是最難的部分。如果您使用廣告，則除了通過http接受第三方廣告外，您別無選擇，這存在安全風險。如果這樣做，則在iframe中投放廣告（請勿使用SCRIPT SRC將廣告集成到您的網頁中）。

  可以加載第三個託管的圖片第三方主機，只要它們通過HTTPS加載（避免出現混合內容警告）。問題。其餘是可以在特定地點進行評估的細節，但在我看來，它們的重要性可能是次要的。

  如果想花哨的話，可以看看證書固定和類似的新興技術，但是從以上四個方面開始已經是一個足夠重要的項目。

用戶的安全性

• 您缺少一個非常重要的東西：CSRF緩解措施。

  請務必充分理解相關問題。 Tldr：在授權令牌（例如，會話cookie）的添加中，您需要 per 操作以識別該操作是用戶意圖還是意外行為。

• 修復 JSONP洩漏。

• X-Content-Type-Options： nosniff （在所有頁面上）以防止MIME嗅探，對於用戶生成的頁面， 尤其是。

• 內容安全策略。

• 確保安全的“重置密碼”機制可防止他人重置他人的密碼並獲得欺詐性訪問權限。

• 當用戶使用弱密碼或完全不接受它時，顯示巨大 巨大警告。

• 培訓用戶（也許通過指向綠色欄的每個頁面上的箭頭圖像）來檢查您的頁面是否加載了HTTPS。如果他們曾經使用不支持HSTS的瀏覽器，至少他們會注意到缺少HTTPS。

服務器/用戶的安全性

• 確保不會由於定時 攻擊而洩露機密。

用戶隱私

• 僅對ajax應用填充是不夠的。要保護用戶不受網絡監視，必須對所有請求和響應進行數據填充。不需要對請求進行時間填充，但是必須進行響應。

• 由於響應時間的差異，

>

假設Alice正在網上沖浪，並且她訪問了Bob的網站，網址為 http://www.bob.com 。鮑勃想找出愛麗絲是否已訪問查理的網站（ http：//www.charlie。com ）。

首先，鮑勃（Bob）查看查理（Charlie）的網站，然後選擇該網站的任何訪問者都可以看到的文件。假設鮑勃在 http://www.charlie.com/ logo.jpg上選擇了包含查理公司徽標的文件。 Bob將確定徽標文件是否在Alice的網絡緩存中。如果文件在緩存中，那麼她一定是最近訪問過Charlie的網站。

Bob編寫了一個Java小程序來實現其攻擊，並將其嵌入到他的主頁中。當愛麗絲查看攻擊頁面時，該Java小程序將自動下載並在愛麗絲的瀏覽器中運行。小程序測量訪問 http：// www所需的時間。在Alice的計算機上運行charlie.com/logo.jpg ，並將這次報告給Bob。如果時間少於某個閾值（例如80毫秒），則鮑勃認為愛麗絲最近去過查理的網站；如果它大於閾值，他得出結論說她最近沒有去過該站點。

服務器的隱私權

• 確保不受時鐘偏斜攻擊的影響。

可用性

• 在 DoS和DDoS的情況下基於用戶/基於IP的限制。

其他無法修復的雜項（瀏覽器問題）：

• 歷史通過HSTS洩漏