您可以使用HSTS告訴瀏覽器在未來請求中始終使用HTTPS。
您可以使用Cookie安全標誌，此標誌從現在開始僅通過HTTPS發送Cookie。
p>您可以使用基於DNS的重定向，但只能在HTTP請求到達後使用。.
我的問題是如何確保用戶始終以HTTPS身份訪問該站點，並且永遠不會通過HTTP發送任何數據
編輯：
鑑於此問題缺乏解決方案，我認為瀏覽器默認應自動發送https請求，然後降級就不起作用了。 s>
評論摘要（並通過替換我以前的回答）：只要sslstrip可能，攻擊者就可以冒充用戶並控制會話，而瀏覽器認為用戶可以控制會話。只有HSTS可以阻止sslstrip，只有HSTS預載可以在第一個請求上阻止sslstrip（在獲取HSTS標頭之前）。
因此， Benoit Esnard的答案正確指出了HSTS預加載的方式。
問題在於，HSTS預加載可能要花費數月才能用於新域，因為更新的列表僅隨新版本的瀏覽器一起提供（至少對於Google Chrome瀏覽器而言）。
換句話說：沒有解決方案可以在短時間內實現。
將您的網站提交到 HSTS預加載列表。
HSTS預加載列表是瀏覽器中嵌入的主機名列表，使他們可以知道哪些網站必須以HTTPS爬網。僅，這樣可以防止任何非HTTPS請求。
您所描述的被稱為會話固定攻擊（Wikipedia鏈接）。
簡而言之，問題在於攻擊者可以為您提供會話標識符cookie。您使用此cookie登錄，服務器會將您的身份與此cookie關聯。
攻擊者仍然知道您的會話ID cookie，並且可以假裝自己是服務器。攻擊完成。
要對此進行防禦，服務器必須在有人登錄時更改會話ID cookie 。攻擊者將獲得陳舊的毫無價值的cookie，無法採取任何措施。
並非所有的Web框架都允許您更改會話cookie。如果這是一個問題，則可以為此使用其他cookie，即框架不知道的單獨的“經過身份驗證的cookie”。每次登錄時也必須更改此Cookie。
鑑於沒有一種完整的方法可以阻止客戶端嘗試連接到HTTP（可能使用cookie）...我們的挑戰是找到減少發生頻率的方法。
一種方法是根本不支持HTTP。讓任何HTTP請求超時（不重定向，不執行任何操作）。這樣可以減少其他站點鏈接到您的HTTP地址的機會，因為這樣的鏈接將不起作用。隨著時間的流逝，希望鏈接到您網站的每個人都可以直接鏈接到HTTPS。
您不能阻止cookie第一次通過HTTP提交 ，但是您可以採取措施以最大程度地減少由此造成的損害。基本原則是，您永遠不要兌現通過HTTP提交的任何信息，並且每當您收到明文形式的敏感信息時，都將這些信息視為已洩露。
設置您的站點以從HTTP重定向到HTTPS，並開始發送Strict-Transport-Security標頭。 （您不必準備好進行預加載，直到您做好準備並準備好為止；無論如何，我要說的都是可行的。）
然後，每當您看到通過明文HTTP提交的cookie時，所有內容都會失效服務器端的那些cookie中。此時請勿嘗試將其從瀏覽器的Cookie罐中踢出，因為由於多種原因不能保證它能正常工作（明文HTTP響應無法處理標記為“安全”的Cookie，較舊的瀏覽器可能會忽略max-age = 0 ，中間人可能會完全剝掉Set-Cookie，以使受害者使用受感染的Cookie）。但是當它們出現在後續的HTTPS請求中時，不要尊敬它們。此時（即，僅當您建立了安全通道時），發出新的會話令牌並要求用戶再次登錄。
類似地，如果您看到登錄表單 em， >以明文形式提交，不僅會使會話cookie失效，鎖定帳戶。 請勿將帳戶恢復，登錄或註冊表單從HTTP重定向到HTTPS；而是發出一條錯誤消息，指示人員手動修復URL（就像驗證碼，但這是為了繞過sslstrip;-中的URL重寫）。通過明文訪問時，應僅由登錄用戶訪問的任何頁面都應重定向到首頁，而不是HTTPS本身。
此外，請確保您的會話Cookie都是不可偽造的和毫無意義的。如今，大多數Web框架都會自動為您執行此操作，但是如果您還沒有，那麼最簡單的構造方法是：每個會話Cookie都很大（生成的隨機數足夠（64位就足夠，128位就足夠了））通過具有加密安全性的RNG，再加上消息驗證碼對該號碼進行簽名。您可以為此使用對稱MAC，因為cookie僅需要由站點進行身份驗證，該站點與發布MAC的實體相同，因此兩次都將知道相同的秘密。如果Cookie附帶了無效的MAC，請忽略它，無論您如何獲取它-假設您根本沒有得到它。 （這甚至取代了有關使通過HTTP傳入的cookie無效的規則。您不希望攻擊者能夠通過偽造請求來強制註銷用戶。）但是，如果MAC有效，則可以使用隨機數作為記錄與用戶會話相關的所有實際信息的數據庫表的密鑰。
最好的做法是，在有人嘗試登錄之前完全不發布任何cookie。 MITM可以獲取有效的Cookie，這也使您更容易遵守GDPR。
在閱讀了關於其他答案的討論後，我現在意識到OP與一個非常特殊的情況有關：該站點的新用戶首次通過人工訪問中間人正在終止HTTPS，剝離HSTS並重寫所有鏈接，然後將未加密的站點中繼給假設的新用戶。確實，與此相對，唯一可能有用的是HSTS預加載。在沒有HSTS預加載的情況下，新用戶的帳戶將像以前一樣“天生就被盜用”，攻擊者將了解有關的所有信息：不僅是會話Cookie，而且用戶名和密碼以及用於帳戶恢復的電子郵件地址，以及受害者輸入的所有個人信息。
但是，如果您只有一次機會通過未受到積極篡改的渠道與用戶互動，則可以推動HSTS和安全的會話cookie和上面的所有建議將很有用。