顧客提交網址後，系統應否由伺服器直接抓取該網站？

先分清顯示連結與伺服器抓取

顧客在產品評價、支援個案或個人檔案貼上一個網址，系統可以只把它顯示成供人自行開啟的安全連結，也可以由伺服器主動連線，擷取標題、預覽圖片或遠端檔案。兩者風險完全不同。伺服器能接觸的網絡及憑證，未必是顧客瀏覽器能接觸的。OWASP 把伺服器端請求偽造稱為 SSRF：攻擊者利用應用程式與其自身或內外網絡互動；遠端圖片及回呼網址都是例子。第一個商業決定是，預覽或匯入對顧客是否真有足夠價值，值得加入這種額外能力。

若業務只是讓員工查看顧客提供的參考資料，把網址當作不可信內容保存，再清楚顯示為外部連結，可能已足夠。介面仍須正確處理輸出及連結安全，但伺服器毋須因此對外連線。若必須檢查供應商文件或預覽指定平台的商品頁，就應列明允許的業務目的地及需要擷取的資料。功能名稱叫「預覽」，並不代表可以暗中接受所有網址。客服流程確實需要看資料，也不表示應用程式應連到顧客或被盜帳戶任意指定的主機。

限制目的地及實際連線

OWASP 的 SSRF 防護指引建議，在可預先知道目的地時使用允許清單。應以成熟網址解析器處理輸入，為功能定義可接受的通訊協定、主機及連接埠，並拒絕把帳戶資料藏在網址內。單靠搜尋某些「危險字眼」，不足以建立安全界線。若功能真的要接觸任意公開網站，設計會更複雜：要檢查 IPv4 與 IPv6 解析結果、拒絕私人、回環、鏈路本地及其他不允許位址，並確保實際連線使用已驗證的位址。OWASP 特別提醒，驗證與連線之間若另作一次未檢查的 DNS 查詢，保護便可能失效。所選 HTTP 用戶端及網絡路徑要當成同一系統審查。

重新導向亦要有獨立規則。看似合適的公開網址，可能回覆跳轉到另一個目的地。OWASP 建議此類功能停用自動跟隨重新導向，因跳轉可繞過輸入驗證。若業務確需跟隨，應把每個新位置當作全新而不可信的網址，重新套用完整的目的地政策，限制最多跳轉次數，並再檢查最後實際連線。不要把認證標頭、Cookie 或內部憑證轉送到顧客控制的目的地。預覽請求不應繼承員工瀏覽器工作階段，也不應帶上供另一服務使用的伺服器權杖。這些是設計條件，不是宣稱某個網站現時已經安全。

網絡設定應提供第二道界線。讓抓取程序經過只准連接必要目的地的對外存取政策，拒絕內部管理服務及雲端中繼資料端點；抓取程序本身持有的憑證亦應減至最低。設定連線及整體逾時、回應大小上限與可接受的內容類型；對方網站一直不回應或傳回龐大二進位檔時，不應長期佔用服務資源。即使連線目的地獲允許，收到的 HTML、圖片及標頭仍是不可信資料。目的地檢查通過，不等於文件內容可靠。只保存功能確實需要的資料，亦不要未經適當審查及呈現控制，就把顧客指定的遠端內容直接放上公開頁面。

用安全測試目的地演練功能

例如香港零售商希望支援個案只預覽自家說明中心及一個簽約供應商平台的連結。允許清單可明確列出這兩個目的地，預覽服務只擷取所需的有限資料。顧客貼上一個會跳到其他地方的短網址時，用戶端不自動跟隨，介面說明預覽未能提供，但保留原始個案文字，讓員工判斷。若供應商日後更換主機，員工應循既有供應商關係核實，再有意識地更新清單，而不是為了修好一次預覽，就放寬至所有公開位址。

測試個案應根據政策設計，而不只是列幾個出名的危險網址。至少包括允許主機、未列入清單的主機、不支援的通訊協定、網址內藏憑證、跳到禁止目的地的重新導向，以及兩次查詢之間 DNS 結果改變的主機。還要涵蓋 IPv6，以及字面看似公開、解析後卻指向內部範圍的位址。在受控測試環境核實被拒請求從未到達受保護網絡。逾時、超大回應及格式錯誤內容也要測；介面應在合理時間內交代預覽失敗，並保留顧客原訊息。日誌可記下政策判斷及目的地類別，但不應複製網址中的秘密資料。

上線後亦要有人負責：誰批准新增目的地、誰查看預覽被拒的報告、網絡界線失效時誰可暫停抓取服務。供應商合約或雲端環境有變，應重新核對允許主機及對外連線權限。如果現有技術無法在連線當刻核實位址，或無法可靠檢查重新導向，就先保留較簡單的外部連結體驗。驗收結果應可觀察：合法而獲准的預覽可運作，不允許的路徑均被阻止，而預覽不可用時顧客仍能提交有用個案。這才是完整顧客旅程，不能只靠網址驗證器的單元測試代替。

為服務定出可維護的界線

「完全沒有預覽」與「任意網址均可抓取」之間，其實有多種產品選擇。零售商可只顯示顧客提交的主機名稱，讓員工自行開啟；也可只預覽自家說明中心或少數核准供應商；遠端圖片或許只接受已驗證商戶整合，而不向所有顧客開放。各方案帶給顧客的好處及需要管理的界線都不同。先用業務語言寫下政策：誰能提交網址、哪個功能會使用、伺服器取得甚麼、失敗時顧客看到甚麼、誰有權擴大目的地清單。

網址未必直接來自同一個網頁表格。背景工作可能在顧客提交數小時後讀取資料庫中的連結；客服員工可能把顧客網址貼進內部工具；圖片處理程序可能跟隨文件中引用的遠端資產。應盤點每個把已儲存文字變成對外請求的元件。原表格驗證固然有用，卻不能是唯一控制，因後續工作可能讀取舊資料、匯入紀錄或由其他介面寫入的值。目的地檢查應放在實際抓取的界線，前端則在可行情況下及早給出易懂的回饋。

預覽被拒不等於顧客有惡意。網址可能不受支援、暫時無法解析，或不屬服務批准的供應商。介面應交代實際結果：訊息或參考網址已保存，但未產生預覽；顧客可修正連結，也可繼續而不使用預覽。員工可看到簡潔的原因類別；合法供應商更換網域時，亦應有上報途徑。對顧客毋須展示內部 IP 規則或網絡架構細節。這樣既維持安全界線，也不會把正常支援流程變成對顧客的指控。

審查現有系統時，不要因輸入驗證成功便假設安全。應在受控環境觀察抓取程序真正發出的請求，包括 DNS 解析後實際使用的位址及重新導向行為。代理設定、圖片函式庫及無頭瀏覽器工具，都可能另開一條未檢查的路徑；需要一併核實。防護措施應能承受一般軟件更新及供應商網域變更。保留簡短變更紀錄，寫明負責人、用途、允許主機及測試結果，讓未來維護者分辨有意批准的例外與遺留的過寬權限。