01 / 網頁傳輸安全
問號與井號分隔不同部分
網址中的問號通常開始 query string，例如 ?page=2；井號開始 fragment，例如 #section-3。
查詢參數常用來告訴伺服器篩選、頁碼或狀態，會成為 HTTP 請求目標的一部分。
片段通常不隨 HTTP 請求傳給伺服器，而由瀏覽器用來定位頁面區段或交給前端程式處理。
這是一般瀏覽器傳輸規則，不表示井號後資料天然安全。頁面中的 JavaScript 仍可讀取片段內容。
02 / 網頁傳輸安全
查詢參數容易進入多種日誌
伺服器、反向代理、CDN、分析工具與錯誤報告可能記錄完整請求網址，因此查詢參數可能被多處保存。
網址也可能出現在瀏覽器歷史、書籤、截圖和客服訊息中。把密碼或長效 Token 放進 query 會擴大暴露面。
頁面載入第三方資源或跳轉時，來源資訊亦可能洩露部分網址；現代 Referrer Policy 可限制，但不能代替安全設計。
敏感憑證應透過合適的請求主體或安全 Cookie 傳送，並配合 HTTPS、短效期限與伺服器驗證。
03 / 網頁傳輸安全
片段不進伺服器但會進前端環境
由於伺服器一般收不到 fragment，純後端路由無法直接根據 # 後內容產生不同首次回應。
前端程式可以透過 location.hash 讀取片段，第三方腳本若在同一頁執行，也可能接觸這項資料。
某些登入流程過去會把短效資料放在片段以減少伺服器日誌暴露，但仍需立即清除、限制腳本和防範 XSS。
片段出現在瀏覽器畫面和歷史中，也可能被使用者複製分享。『不傳伺服器』不等於『只有本人可見』。
04 / 網頁傳輸安全
編碼不等於保密或驗證
URL 百分號編碼只是讓特殊字元可安全放入網址，例如空格變成 %20；任何人都能還原。
Base64URL 同樣是編碼格式，不是加密。把 Token 變成看似亂碼，不能防止取得網址的人使用。
伺服器收到參數後仍要驗證型別、允許值、權限與時效，不能因它來自自己頁面的連結便直接信任。
前端也應避免把未處理參數直接插入 HTML，否則可能形成跨站腳本等注入風險。
05 / 網頁傳輸安全
使用者與開發者的最小暴露原則
使用者不要把含長串 Token、重設碼或個人識別參數的完整網址貼到公開平台；必要時先從可信入口重新操作。
開發者應只在網址放完成導航所需的非敏感資料，縮短一次性憑證期限，使用後失效，並從日誌遮罩。
技術上安全的網址處理不會證明網站內容公平、業務合法或交易可靠，這些需要不同層次的獨立查核。
本文僅供知識分享，請理性看待；本站不接受投注、不提供註冊或博彩平台連結。數位安全不能取代時間與支出界線。